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SECTION  I 
INTRODUCTION 


A  major  transition  from  a  batch  oriented  card  and  tape  processing  system 
to  an  interactive  on-line  retrieval  and  update  system  was  planned  and  imple¬ 
mented  by  Synectics  Corporation  for  the  Automated  Air  Information  Production 
System  (AAIPS) . 

The  total  Synectics  effort  encompassed  three  subsystems:  Air  Facilities, 
Publishing,  and  Charting.  This  technical  report  describes  the  Air  Facilities 
subsystem,  its  background,  objectives,  implementation  concepts,  and  operational 
characteristics. 


1.0  Background 


The  Automated  Air  Information  Production  System  (AAIPS)  has  been  imple¬ 
mented  by  the  Synectics  Corporation  under  contract  to  Rome  Air  Development 
Center  for  the  Defense  Mapping  Agency's  Aerospace  Center,  The  scope  of  this 
effort  covered  the  analysis,  as  well  as  the  design  and  specification  of  all 
hardware  and  software  components  comprising  each  subsystem  of  AAIPS.  The 
effort  included  the  acquisition  and  integration  of  all  hardware  components 
and  custom  software  to  create  a  Pilot  system  during  this  Phase  I  effort.  A 
demonstration  of  all  Pilot  subsystems  operating  collectively  to  manage  and 
process  l/15th  of  the  normal  AAFIF  work  flow  constituted  the  major  evaluation 
criteria  for  determination  of  whether  to  pursue  Phase  II  of  the  AAIPS  program. 


1.0.1  Major  Objectives  and  Management  Approach 


The  employed  strategy  for  the  development  of  the  Air  Facilities  subsystem 
has  bf-Ti'i  that  of  management  by  objectives.  The  establishment  of  these  objec¬ 
tives  provided  the  guidelines  by  which  the  system  goals  have  been  reached. 
These  objectives  were  outlined  as  follows: 


o  Establish  milestones  by  which  progress  can  be  measured 
o  Provide  support  to  process  1/15  of  the  AAIPS  workload  (Phase  I) 
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o  Provide  an  AAFIF  data  base,  eliminating  redundancy  and  wasted  space 

o  Provide  an  on-line  interactive  capability  to  update  and  retrieve 
data  from  that  data  base 

o  Retain  maximum  flexibility  for  the  user  to  change  or  redefine 
essential  system  functions  without  future  software  changes  or 
vendor  support 

o  Upgrade  the  built-in  machine  intelligence  to  achieve  greater  infor¬ 
mation  integrity  and  a  better,  automatic  supervision  of  on-line 
transactions 

o  Simplify  and  speed  up  the  bulk  of  regular  operating  procedures  for 
major  savings  of  operating  costs  and  faster,  up-to-date  service 

1.0.2  AD  Production  Overview 

The  Aeronautical  Information  Department  (AD)  of  the  Defense  Mapping 
Agency  Aerospace  Center  (DMAAC)  is  responsible  for  the  acquisition,  maintenance 
evaluation  and  exploitation  of  aeronautical  information  to  support  Defense 
Mapping  Agency  (DMA)  Aerospace  Charts  and  Flight  Information  Publications 
(FLIPS)  distributed  worldwide.  This  information  is  provided  to  the  Depart¬ 
ment  of  Defense  (DoD)  and  other  agencies  and  authorized  users  for  flight 
operations  and  logistical  planning  purposes. 

The  major  AD  production  programs  include: 

o  DoD  Flight  Information  Publications  (FLIPS) 

o  Navigation/Planning  and  Special  Purpose  Charts 

o  Special  Products 

o  Automated  Air  Facility  Information  File  (AAFIF) 


1.0. 2.1  Flight  Information  Publications 

FLIPS  products  are  associated  with  the  following  geographical  areas: 
o  Alaska 

o  Pacific,  Australia,  Asia,  Antarctic 
o  Canada  North  Atlantic 

o  United  States 

o  Caribbean  South  America 
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o  Europe  North  Africa  Middle  East 
o  Africa 

For  each  geographical  area  AFLIPS  of  the  following  general  types  are 
produced:  Planning  Documents,  Enroute  Charts  and  Supplements  and  Terminal 

Procedures. 

1.0. 2. 2  Enroute  Charts  and  Supplements 

These  publications  consist  of  83  flights  charts  and  six  textual  supple¬ 
ments.  The  kinds  of  information  contained  within  these  documents  are: 

o  airway  system/special  use  airspace 
o  aerodrome  data 

o  navigational  facilities 

Collectively,  the  Enroute  Supplements  contain  140,000  lines  of  text  and 
almost  11  million  characters  of  information.  Nearly  45,000  update  transactions 
are  performed  on  these  documents  annually.  These  transactions  represent  over 
62,000  lines  of  text  changes.  The  Enroute  Supplements  for  foreign  countries 
also  contain  sketches  of  selected  aerodromes  and  heliports. 

The  Enroute  Charts  are  produced  in  the  large  graphic  format  (20"  x  45") 
and  typically  require  over  800  changes  per  year. 

1.0. 2. 3  Aeronautical  Information  Special  Products 

The  special  products  are  of  three  varieties: 

o  Aeronautical  Video  Mapping 

o  Tactical  Situation  Displays 

o  Air  Field  Diagrams 

1.0. 2. 4  Automated  Air  Facilities  Information  File  (AAFIF) 

The  AAFIF  system  satisfies  requests  for  free  world  air  facility  informa¬ 
tion  and  to  support  contingency  planning  functions  of  DoD  approved  user 
organizations.  It  is  an  automated  file  of  evaluated  information  pertaining 
to  all  foreign  free  world  airways.  Approximately  46,000  airfield  records  are 
currently  maintained.  Around  2,000  information  updates  to  AAFIF  are  received 


by  AD  daily.  The  actual  physical  size  of  AAFIF  is  in  excess  of  400  million 
characters.  With  the  old  system  this  information  resides  on  21  reels  of  mag¬ 
netic  tape.  The  informational  content  of  AAFIF  is  categorized  as  follows: 


■ 

o  General  Identification  and  Description 
o  Operational  Users 

o  Navigation  Aids  and  Communications 

o  Airfield  Description 

o  Maintenance  and  Servicing 

o  Special  Purpose  Equipment  Base  Services 

o  Transportation  Weather 

Outputs  derived  from  AAFIF  source  information  are  recorded  on  magnetic 
tape  or  printed.  A  total  of  about  90  different  products  constitute  the 
scheduled  production.  Roughly  30  of  these  products  are  in  the  form  of  digital 
tapes  and  the  remaining  60  products  are  hardcopy  printed  reports.  Scheduled 
product  users  are: 

o  Defense  Intelligence  Agency  (DIA) 

o  World  Wide  Military  Command  and  Control  System  (WWMCCS) 

o  Other  U.S.  Government  Agencies 

Currently  the  yearly  average  magnetic  tape  production  is  about  800 
tapr-<f  with  an  average  weekly  production  of  15  tapes.  Peak  load  activity 
occurs  with  the  coincidence  of  varying  production  cycles  and  may  mount  to 
as  high  as  100  tapes  per  week.  The  volume  of  hardcopy  printed  material  is 
in  the  neighborhood  of  700,000  printed  pages  per  year,  which  averages  13,000 
pages  weekly  and  realizes  a  peak  load  of  about  80,000  pages  per  week. 

AAFIF  was  initially  implemented  in  1960.  In  1964  a  file  expansion  study 
was  performed  which  resulted  in  the  first  automated  file  design  and  the  crea¬ 
tion  of  the  ASSOTW  as  output  from  this  file.  The  implementation  of  the 
COBOL-bases  system  was  completed  in  1968  on  an  IBM  7094  computer  system. 

Obsolescence  of  the  IBM  7094  resulted  in  a  conversion  to  the  Univac  1108  which 
was  completed  in  1976.  The  existing  AAFIF  system  includes  both  the  data  base 
and  the  ADP  programs  necessary  to  maintain  and  retrieve  the  information  within 
the  data  base.  Present  AAFIF  content  was  validated  by  a  user  Purvey  in  1974. 


4 


1 . 0 . 2 . 5  Organizational  Responsibility 

The  Aeronautical  Information  Department  has  several  divisions  to  fulfill 
its  functional  role.  Of  those,  ADA,  the  Automated  Systems  Division,  is  charged 
with  the  responsibility  of  processing  and  maintaining  the  AAFIF  data  base  and 
the  generation  of  scheduled  data  products  derived  from  exploitation  of  the 
Air  Facilities  information.  ADA  also  provides  immediate  response  to  ad  hoc 
Special  Air  Information  Requests  (SAIRS) . 

1.0. 2. 6  AAFIF  Processing 

Operational  control  of  AAFIF  maintenance  and  applications  processing  is 
the  responsibility  of  ADA  personnel,  who  currently  submit  batch  jobs  to  1108 
computer  operators.  Completed  jobs  are  returned  to  ADA  for  distributing  the 
outputs  to  appropriate  end-user  organizations. 

The  data  base  updating  with  the  current,  batch  oriented  Univac  1108  sys¬ 
tem  is  performed  on  a  weekly  basis.  Scheduled  query  products  are  produced 
weekly,  monthly,  quarterly,  semiannually  and  annually.  Unscheduled  products 
(SAIRS)  are  generated  as  needed.  The  latter  occur  at  the  nominal  frequency 
of  around  100  per  year.  The  outputs  of  95  percent  of  the. SAIRS  are  printouts. 
Very  small  percentage  of  SAIRS  generate  digital  tape  products.  Turn  around 
time  on  the  U1108  for  the  SAIR  production  programs  is  typically  24  hours. 

The  batch  oriented  AAFIF  updating  is  initiated  by  Air  Analysts  in  ADD 
who  prepare  special  data  entry  forms  for  the  AAFIF  system.  The  data  entry 
forms  are  then  transferred  to  the  keypunching  contractor.  Keypunched  data 
cards  are  returned  to  ADA  for  entry  into  the  AAFIF  system.  The  cards  are 
then  transferred  to  magnetic  tape  by  an  off-line  process  through  an  IBM  1401 
system.  The  transaction  file  (update  card  on  tape)  is  the  input  to  the  AAFIF 
be^^h  update  process  performed  weekly.  Each  transaction  is  edit  checked  and 
verified  automatically  during  the  AAFIF  updating.  A  feedback  report  of  AAFIF 
updates  is  generated  as  a  by-product  of  the  AAFIF  update  process  and  is 
returned  to  the  Air  Analysts  in  ADD  for  confirmation.  The  present  update/ 
input  system  creates  delays  of  several  weeks  in  getting  analyst  changes  into 


the  AAFIF  data  base. 


A  major  objective  for  the  redevelopment  of  the  Automated  Air  Information 
Production  System  (AAIPS)  by  Synectics  Corporation  was  the  transformation  of 
the  current  data  management  system  into  a  fast  responding,  interactive  on-line 
capability . 

1.1  Purpose 

The  main  purpose  of  the  Phase  I  effort  has  been  the  creation  of  an  on¬ 
line  retrieval  and  update  system  that  permits  interactive  dialogs  between 
users  and  the  computer  for  a  more  efficient  and  timely  maintenance  of  the 
AAFIF.  Included  in  this  objective  is  the  requirement  for  a  ’clean’  data  base 
in  the  years  ahead. 

The  latter  is  of  importance  for  the  simple  reason  that  the  frequently 
updated  data  base  information  will  be  extracted  for  the  generation  of  reports 
or  magnetic  tapes  that  are  passed  on  to  other  departments  of  DMAAC,  as  well  as 
to  various  other  agencies.  Since  these  reports  and  tapes  serve  as  inputs  for 
decisionmaking  or  further  data  processing  at  these  locations,  correct  informa¬ 
tion  is  essential  to  avoid  costly,  time  consuming,  and  embarrassing  situations. 

While  'timeliness'  and  'cleanliness'  of  the  data  base  operations  are  of 
supreme  importance  to  the  Air  Facilities  system,  a  greater  operating  efficiency 
is  also  desired  for  achieving  major  operating  cost  reductions  in  the  future. 

As  the  volume  tests  of  the  Pilot  system  indicate,  the  possible  cost  savings 
promise  to  be  of  substantial  proportions. 

A  high  degree  of  built-in  'machine  intelligence'  is  desirable  for  the 
purpose  of  controlling  the  on-line  operations  through  expanded  supervisory 
functions  with  automatic  communications  feedback  in  the  case  of  input  error 
or  required  user  decision.  By  reducing  the  'cost'  of  input  errors  and  user 
guidance-- in  terms  of  time  delays  or  loss  of  data  base  integrity --the  manual 
operations  become  less  critical.  Format-incorrect  or  illogical  entries  just 
have  less  chances  of  getting  accepted  by  the  new  system.  This  not  only  serves 
the  purpose  of  speeding  up  the  data  entries,  it  also  tends  to  relax  the 
requirements  for  specific  operator  experience.  The  latter  provides  relief 


and  greater  flexibility  to  the  problems  of  work  assignment  and  personnel 
management. 

Any  automated  information  system  that  wants  to  avoid  premature  obsoles¬ 
cence  must  make  provisions  towards  future  systems  evolution,  with  the  poten¬ 
tial  for  ever  increasing  sophistication  and  automation.  In  the  case  of  Air 
Facilities  this  means  that  many  of  the  currently  manual  input  operations  must 
be  expected  to  become  replaced  by  -update  information  in  machine-readable  form 
or  by  transmissions  via  direct  computer- to-computer  interfaces.  For  this 
reason  a  software  approach  is  required  that  covers  the  full  spectrum  from 
manual  inputs  with  relatively  simple  edit  checks  (i.e.  human  supervision)  to 
most  sophisticated  editing  procedures  for  automatic  entries  and  computed 
inputs.  By  incorporating  programs  that  allow  the  full  range  of  data  correla¬ 
tion  and  editing  sophistication,  the  purpose  of  system  stability  can  be 
achieved  regardless  in  what  mix  of  manual  to  automated  inputs  the  system  is 
actually  used  at  any  given  time. 

Another  major  objective  of  system  design  is  a  clear  separation  between 
functions  for  regular,  daily  operations,  such  as  updating  the  AAFIF  data  base 
(ADA  operators) ,  and  those  of  determining  and  redefining  important  editing 
and  processing  programs  for  the  system  itself  (ADA  systems  personnel) .  The 
obvious  purpose  of  this  functional  separation  is  the  greater  clarity  and 
management  economy  with  which  those  functions  can  be  defined,  organized, 
staffed,  and  supervised. 

There  is  an  important  prerequisite  for  retaining  system  control  in  areas 
vital  to  ADA.  This  prerequisite  demands  that  important  system  changes  can 
readily  be  implemented  through  data  entries  in  pertinent  edit  and  system  con¬ 
trol  tables,  rather  than  through  reprogramming  efforts  and  software  changes. 

The  latter  are  time  consuming  and  require  critical  steps  such  as  recompila¬ 
tions,  link-editing  procedures,  memory  reallocations,  and  documentations. 

This  usually  leads,  sooner  or  later,  to  a  ’roadblock'  situation  where  further 
system  improvements  and  modifications  are  prevented.  In  contrast,  it  was  the 
expressed  purpose  of  the  new  design  to  provide  ADA  system  personnel  with 
effective  means  to  change,  mold,  and  redefine  those  vital  system  functions  with¬ 
out  encountering  those  obstacles  that  tend  to  become  insurmountable  in  time. 
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SECTION  II 

FUNCTIONAL  REQUIREMENTS 

To  develop  a  Pilot  system  as  outlined  in  the  preceding  section  the  fol¬ 
lowing  functions  had  to  be  implemented. 

2 . 0  Subsystem  Requirements  and  Capabilities 

For  a  summary  of  the  Air  Facilities  subsystem  functions  see  the  enclosed 
Figure  2-1.  This  figure  describes  in  a  simplified  manner  the  inputs,  proces¬ 
sing  functions,  and  outputs  generated  by  the  system.  The  following  paragraphs 
provide  a  breakdown  in  greater  detail. 

2.0.1  Hardware  Selection/Operational  System 

o  Design  a  hardware  configuration  that  will  meet  or  surpass  the 

requirements  for  the  subsystem  as  stated  in  the  Statement  of  Work 

o  Provide  a  matching  operational  system  that  meets  all  requirements 
of  the  computer  system 

o  Generate  a  'cookbook'  for  system  usage  and  the  maintenance  of  files 
2.0.2  AAFIF  System  Programs 

O  Design  System  Tables  for  display  control,  data  base  element 
identification,  and  edit  table  selection 

o  Provide  capability  for  establishing  password  tables  and  their  easy 
modification 

o  Develop  edit  tables  for  format  tests,  logical  correlations  of  data 
base  elements,  computed  (automatic)  inputs.  Boolean  retrievals, 
password,  and  Geo-Id  correlations 

o  Provide  inprt  programs  with  table  headers  and  automatic  tab  settings 
for  the  on-line  creation  of  system  and  edit  tables 

o  Create  test  programs  for  the  on-line  testing  and  changing  of  edit 
tables 

o  Implement  a  display  session  file  with  hardcopy  output  for  edit  table 
documentation 

o  Provide  a  card  input  program  for  the  'wholesale'  loading  of  generated 
edit  tables 

o  Devise  programs  for  formal  table  checks,  load  module  generation  and 
systems  loading 
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AIR  FACILITIES  SUBSYSTEM  FUNCTIONS 


2.0.3  On-Line  Capability 


Provide  a  capability  to  perform  AAFIF  data  base  maintenance  by  per¬ 
mitting  the  operator  to  add,  change  or  delete  indivirual  data  elements  or 
whole  records  with  ease  and  timeliness. 


2. 0.3.1 

o 


o 


o 


2.0. 3.2 

o 


o 


o 


2. 0.3. 3 

o 


o 


2. 0.3. 4 

O 


o 


Log-on/Log-off 


Include  an  access  authorization  capability  through  a  combined  pass¬ 
word  processing  and  geographic  identifier  validation  scheme.  Corre¬ 
late  password  and  geographic  identifier  for  proper  match 

Ensure  that  the  operators  cannot  access  the  command  language  of  the 
operating  system  (CLI)  or  the  facilities  of  the  AAFLF  system  programs 

Provide  a  log-off  function  with  reactivation  of  all  access  controls 


Display  Processing 

Generate  display  files  or  menues  for  on-line  communications  that 
lead  the  operator  as  well  as  the  on-line  software  to  proper  display, 
decision,  and  processing  sections 

Make  the  display  processing  functions  safe  (avoidance  of  system 
crashes)  as  well  as  clear  and  self-explanatory  (teaching-machine 
characteristics) 

Create  display  files  and  display  file  structures  with  application 
area  designations,  retrieval  indexes,  display  text,  header,  and 
communication  (error)  messages,  and  subroutine  call  arguments 

Input  Processing 

Program  a  special  on-line  data  input  module  with  automatic  cursor 
positioning,  and  'tick  mark'  generation  to  indicate  (and  limit) 
the  input  field  on  the  screen 

Include  simple-to-use  input  conversion  capabilities  such  as 
character  delete,  line  delete,  input  escape,  and  possible  exit  to 
a  previous  program  level 


P.BTRIEVE 

Establish  a  simple  record  identification  procedure  with  retrieval 
modes:  Single  element,  groups  of  elements,  page/continuation  page, 

and  the  retrieval  of  multiple  data  elements  (e.g.  multiple  runways 
per  airfield) 

Provide  a  'copy  display  to  line  printer'  and  a  'print  total  airfield* 
capability 
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2 . 0 . 3 . 5  UPDATE 


o  Allow  for  a  single  element,  group  of  elements,  page/continuation 
page,  and  'multiple'  on-line  update  capability.  Hold  all  updates 
for  final  validation  (logic  checks) 

o  Perform  automatic  format  checks  for  each  data  element  entered.  Give 
immediate  input  error  indication  with  options  to  repeat  or  skip  the 
faulty  data  element  input 

o  Create  a  temporary  file  containing  all  update  information.  Ensure 
that  file  is  saved  in  case  of  system  failures  (e.g.  power  outages), 
or  can  be  requested  to  be  saved  (in  case  of  update-rejections  due 
to  logical  checks)  for  later  continuation  or  update  correction 

o  Perform  logical  checks  that  correlate  selected  data  base  elements 
to  make  sure  that  entries  fall  within  reasonable  ranges  and  that 
right  information  categories  have  been  chosen  (i.e.  make  sense). 
Prevent  updates  that  do  not  pass  logical  checks  from  being  entered 
into  the  data  base 

o  Provide  for  an  automatic  update  function  (computed  input)  that  is 
triggered  by  the  update  of  other  data  base  elements,  correlated  by 
logical  tables.  (Usually  for  a  changeo  data  category  that  repre¬ 
sents  a  group  of  related  elements) 

o  Implement  on-line  text  edit  and  update  capabilities  with  string 
search,  string  replacement,  and  update  verification  schemes 


2. 0.3.6  ADD 

o  Program  a  capability  for  the  on-line  addition  of  an  entire  airfield 
to  the  data  base.  Assure  a  guided,  page-wise  and  item-by-item 
information  entry  that  avoids  skipped  data  fields  and  human  over¬ 
sights 

o  Make  the  elaborate  UPDATE  functions  available  to  the  ADD  process  by 
generally  treating  the  ADD  process  —  including  format  tests,  logical 
checks,  and  computed  inputs —as  an  UPDATE  of  a  (previously  'empty') 
record 


! 


2. 0.3. 7  DELETE 

o  Provide  a  special  password/DELETE  function  correlation  through  a 

system  access  table  in  order  to  ensure  that  the  somewhat  dangerous 
deletion  of  an  entire  airfield  from  the  data  base  can  be  accom¬ 
plished  only  by  special,  designated  personnel 

o  Generate  log  and  special  output  for  deleted  airfields 
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2. 0.3. 8  Transaction  L< 


o  Maintain  a  periodic  access  file  containing  terminal  and  airfield 
information,  geographic  identifier,  date,  and  time-of-day 

o  Keep  log  of  all  transactions  (UPDATES,  ADDS,  DELETIONS)  as  they 
effectively  alter  the  data  base  after  passing  format  and  logical 
checks 

2. 0.3. 9  Save  and  Restart  Capability 

o  Provide  capability  for  using  the  temporary  file  that  contains  all 
update  information  as  a  SAVE  file  to  continue  the  update  process 
after  a  system  outage  or  operator  interruption 

o  Transfer  each  data  base  transaction  to  disk  for  safer  storage  than 
a  file  in  main  memory 

o  Implement  a  deliberate  save-file  capability  to  be  used  by  the 

operator  to  preserve  an  incompleted  update  session.  (Transfer  of 
the  'temporary  file'  to  another  that  will  be  kept  for  later  recall) 

2.0.4  Applications  Program 

The  applications  programs  deal  with  a  larger  section  of  the  data  base 
and  are  intended  to  produce  reports  and  magnetic  tape  outputs  to  be  used  by 
other  departments  of  DMAAC  and  other  agencies. 

o  Provide  a  Boolean  search  capability  (on-line  generated)  for  retrieving 
specific  records/airfields  from  the  data  base  with  prescribed  infor¬ 
mation  contents 

o  Allow  limited  sections  of  the  (world-wide)  data  base  to  be  subjected 
to  the  Boolean  search  capability 

o  Provide  sort  capabilities  that  allow  complex  sort  key  specifications 
and  processing.  Implement  multi-pass  sorting 

o  Provide  a  report  generation  capability  for  both  hardcopy  and  mag 
tape  output 

o  Process  security  classifications  by  inserting  pertinent  notifica¬ 
tions  on  the  output  media 

o  Accomplish  page  breaking,  header,  and  title  page  inserting 

o  Include  print  control  with  column  and  line  spacing  commands 

2 . 1  Workload 

The  AAFIF  data  base  for  the  Pilot  subsystem  must  contain  approximately 
2,200  airfield  records  in  order  to  create  the  1/15  data  base  volume  for  the 
required  acceptance  tests. 


To  exercise  and  test  the  new  system,  pertinent  transactions  are  to  be 
collected  over  a  2-week  period  for  on-line  input,  function  comparisons,  and 
timing.  The  test  material  must  cover  all  functions  specified  and  correspond 
in  quantity  to  the  amount  of  transactions  required  to  demonstrate  the  proces¬ 
sing  capabilities  of  the  Pilot  system. 

2.0.3  Data  Base 

The  data  base  structure  of  the  Air  Facility  Subsystem  must  be  designed 
to . accommodate  all  data  necessary  for  the  Pilot  maintenance  and  update  func¬ 
tions.  The  chosen  structure  must  provide  ready  access  to  single  elements  as 
well  as  groups  of  elements.  Care  has  to  be  exercised  to  avoid  restrictions 
which  would  likely  cause  substantial  redesign  and  conversion  problems  in  the 
future . 

A  major  effort  of  the  project  has  to  be  the  reformatting  of  the  AAFIF 
and  the  establishment  of  unique  retrieval  codes.  At  present  an  airfield  record 
contains  over  600  data  elements  that  have  to  be  organized  in  categories  and 
subcategories . 

The  data  base  elements  can  contain  regular  alpha  or  numeric  fields, 
narrative  text  of  variable  length,  or  multiple  entries  (e.g.  to  accommodate 
the  information  for  several  runways  of  an  airfield) . 


SECTION  III 


SUBSYSTEM  DESIGN 


In  Air  Facilities  a  major  transition  has  been  made  from  a  previously 
batch  oriented  card  processing  system  to  an  on-line  retrieval  and  update 
system  that  permits  interactive  dialogs  between  users  and  the  computer  for 
an  efficient,  up-to-date  maintenance  of  the  AAFIF  data  base.  Along  with 
this  transition  a  considerable  upgrading  of  the  built-in  machine  intelligence 
has  been  implemented  in  order  to  supervise  those  on-line  procedures  for 
correctness  in  both  form  and  information  content.  As  a  result,  the  AAFIF 
data  base  can  be  expected  to  become  much  'cleaner'  in  the  future,  while  the 
requirements  for  operator  experience  and  qualifications  can  somewhat  be 
relaxed . 

3 . 0  Design  Criteria 

The  software  design  has  followed  a  Top-Down  and  Structured  Programming 
design  approach,  as  far  as  this  was  possible  — or  reasonable —within  the 
given  constraints  of  available  main  memory,  required  processing  speed,  and 
the  inherent  features  of  the  chosen  language  (FORTRAN) . 

c'acticality  of  program  implementation,  ease  of  understanding,  and 
possible  modification  as  requirements  change,  were  of  major  design  concern. 
While  not  being  dogmatic  with  regard  to  a  particular  programming  style,  there 
had  been  little  compromise  when  it  came  to  the  question  of  retaining  control 
of  essential  system  functions  for  the  user. 

3.0.1  Table  Implementation  of  Essential  Functions 

To  assume  this  control  down  to  the  element  level  of  the  data  base,  a 
series  of  tables  had  been  created.  The  implementation  of  important  software 
functions  in  table  form  enables  the  user  to  maintain,  to  expand,  and  if 
necessary  to  restructure  the  system  through  data  entries  alone.  By  avoiding 
software  changes  and  reprogramming  efforts  in  areas  most  vital  to  ADA,  a 
high  degree  of  vendor  independence  and  system  flexibility  has  been  achieved. 


14 


This  adaptability  to  changed  situations  will  save  cost  and  time  and  will 
prove  to  be  of  immeasurable  value  in  the  years  to  come, 

3.0.2  Menue-Oriented  On-Line  Control 

Another  area  of  major  concern  was  that  of  on-line  operations.  Instead 
of  developing  a  special  (and  difficult  to  learn)  command  language,  a  menu- 
oriented  display  capability  had  been  chosen  to  achieve  smooth  interfaces 
between  the  user  and  the  computer.  Ib  should  guide  both  operator  and  the 
system  to  any  one  of  the  required  display,  data  input,  processing,  and  error 
checking  routines.  The  man-machine  dialog  should  allow  to  perform  this  task 
in  a  systematic,  safe  and  proper  way  such  that  confusion  as  well  as  system 
crashes  could  be  avoided.  It  should  also  be  self-explanatory  so  that  it 
would  be  possible  for  an  untrained  person  to  become  familiar  with  all  opera¬ 
tions,  just  by  testing  the  various  options  presented  to  him*  In  its  most 
elaborate  form,  the  system  should  be  able  to  fulfill  the  functions  of  a  (very 
patient)  teaching  machine  that  allows  the  self-training  of  personnel. 

3.0.3  System  Security 

Finally,  system  security,  with  an  interlocking  scheme  of  passwords  and 
other  information  such  as  geographic  identifiers,  had  to  receive  important 
design  consideration.  In  addition,  it  was  recognized  that  functional  system 
security  is  of  equal  importance  and  goes  much  further  than  access  control 
alone. 

A  clear  separation  of  functions  between  ADA  system  personnel  (for  main¬ 
taining  the  system  and  redefining  its  behavior),  and  operators  (for  updating 
the  data  base)  was  indicated  in  order  to  better  supervise,  organize,  and 
safeguard  the  day-to-day  operations. 

As  it  stands  now,  the  operator  environment  provides  all  necessary  on¬ 
line  capability  for  maintaining  the  data  base  while  preventing  him  from 
altering  essential  system  functions  (e.g.  the  specification  of  required 
edits)  . 
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The  latter  functions  are  reserved  for  ADA's  system  personnel,  and 
special  software  packages  have  been  provided  for  this  purpose. 

3 . 1  Structure  Overview 

The  structure  of  the  developed  software  can  be  presented  on  two  levels; 
o  Grouped  by  major  processing  functions 

o  As  implemented  in  various  programming  media  such  as  high  level  pro¬ 
gramming  language  and  data  base  system  software 

Both  types  of  breakdowns  are  presented  in  Figures  3-1  through  3-3. 

3.1.1  Major  User  Software 

Three  groups  of  software  routines  have  been  implemented  as  shown  in 
Figure  3-1: 

GENERAL:  The  main  on-line  procedures  with  the  indicated  functions 

as  performed  by  operators  and  system  analysts  to  update  and  main¬ 
tain  the  data  base.  (The  crossing  -  sign  in  the  line  to  the 
’Delete’  box  indicates  that  special  password  restrictions  might  be 
desirable  for  the  function  in  question.) 

SPECIAL:  Special  functions  and  applications  for  generating  output 

tapes  and  reports  (preferably  during  the  off-hours  since  longer 
processing  times  are  involved) . 

ON-LINE  CONTROL:  Supportive  software  routines  for  program  control 
of  the  on-line  features.  These  ’utilities’  will  be  used  extensively 
during  all  on-line  processes.  They  guarantee  on  orderly  man-machine 
dialog  and  minimize  the  potential  for  mistakes  and  formal  input 
errors. 

3.1.2  Major  System  Software 

Figure  3-2  indicates  the  developed  software  for  implementing  system 
tables  and  defining  essential  system  functions  by  ADA  system  personnel.  Each 
group  requires  programs  for  entering,  displaying,  updating  (changing),  and 
systems  loading  of  pertinent  system  control  tables, 

3.1.3  On-Line/INFOS  Interface 

Figure  3-3  shows  the  software  structure  of  on-line  routines,  written  in 
the  high  level  FORTRAN  language  and  their  interactions  with  data  base  ele¬ 
ments  and  system  tables  as  currently  stored  in  Data  Generals  INFOS  data  base 
management  system. 


SYSTEM  FILES  FOR  TABLE-DRIVEN 
PROGRAM  CONTROLS  AND  DISPLAYS 


•  ENTER 

•  DISPLAY 

•  UPDATE 

•  LOAD 


| 
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Figure  3-2  Major  System  Software 


3. 2  Subsystem  Data  Base 


The  AAFIF  data  base  for  the  pilot  subsystem  contains  approximately  2,20Q 
records  of  selected  airfields.  It  is  anticipated  that  with  the  Phase  II 
data  base  of  48,000  airfields  and  a  constant  growth  rate,  there  will  be  about 
2,000  updates  per  day.  The  data  base  structure  has  been  designed  to  accommo¬ 
date  all  the  information  necessary  for  their  update  and  maintenance, 

A  major  effort  of  the  project  was  the  reformatting  of  the  AAFIF,  resulting 
in  a  new  data  base  definition  (Label  Book) .  A  major  feature  was  the  establish¬ 
ment  of  a  unique,  4-character,  retrieval  code  for  each  data  element  of  an  air¬ 
field  record,  and  the  accompanying  descriptive  element  name  (label) . 

The  retrieval  code  is  used  as  an  'address'  to  access  a  specific  airfield 
data  element.  However,  both  retrieval  codes  and  descriptive  element 
names  are  only  stored  once  in  the  system  to  eliminate  redundant  information 
from  storage.  As  a  consequence,  the  actual  data  base  contains  only  the 
'essential'  information  for  the  specific  element  of  an  airfield.  For  the  e  c 
of  human  interpretation,  retrieval  codes,  descriptive  labels,  and  the  actual 
element  information  are  always  combined  on  the  screen.  At  present  an  airfield 
record  contains  over  600  data  elements  organized  in  'pages'  that  correspond 
to  82  subcategories.  The  data  base  elements  can  contain  regular  alpha  or 
numeric  fields,  narrative  text,  or  multiple  entries  (e.g.  to  accommodate  the 
information  for  several  runways  of  an  airfield.) 

The  element  retrieval  codes  and  descriptive  labels  are  stored  in  special 
tables  (Label  Tables) .  In  addition,  important  control  information  is  included 
in  those  tables  for  program  selection,  display  control,  edit,  multiple  and 
text  processing  instructions.  In  this  way  a  data-driven  capability  of  func¬ 
tion  selection  has  been  achieved  that  allows  specific  and  detailed  control 
down  to  the  element  level  of  the  data  base. 

For  the  Phase  I  pilot  system  both  tables  and  data  base  elements  have 
been  stored  on  disk  using  the  Data  General  INFOS  data  base  management  package 
as  outlined  in  the  previously  presented  Figure  3-3. 
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3 . 3  Subsystem  Personnel  Functions 


For  reasons  of  practicality,  manpower  allocation,  training,  supervision, 
and  functional  security,  the  potential  for  a  clear  separation  of  personnel 
functions  has  been  provided.  This  has  been  accomplished  by  creating  special, 
system  oriented  programs  for  loading  tables  or  changing  essential  system 
functions,  as  opposed  to  on-line  capabilities  that  are  data  base  oriented. 

The  strict  separation  of  major  software  functions  enables  a  corre¬ 
sponding  separation  of  personnel  functions:  ADA  system  personnel,  responsi¬ 
ble  for  maintaining  the  system  and  changing  its  behavior  if  necessary,  and 
operator  personnel  for  updating  and  maintaining  the  AAFIF  data  base. 

3.3.1  ADA  System  Personnel 

The  system  personnel  is  responsible  for  defining  essential  system 
functions,  for  table  design,  testing  and  loading,  as  well  as  for  security 
implementation,  password  tables,  and  other  system  supervisory  functions. 

3.3.2  Operator  Personnel 

The  operator  personnel  and  analysts  have  available  at  their  command 
all  necessary  on-line  capabilities  for  maintaining  and  updating  the  AAFIF 
data  base.  However,  they  are  prevented  by  the  design  from  altering  essential 
system  functions,  such  as  specifications  for  required  edits.  Their  program 
framework,  as  intended,  does  not  allow  them  to  even  access  and  use  the  common 
instructions  of  the  Command  Language  (CLI)  provided  by  the  computer  manu¬ 
facturer.  This  prevents  them  from  bringing  the  system  down,  or  conducting 
other  undesired  manipulations  (e.g.  requesting  outputs  of  the  password 
tables).  Since  the  latter  capabilities,  clearly,  are  in  the  domain  of  ADA's 
system  personnel,  they  have  been  separated  and  safeguarded  as  such. 

3.3.3  Definition  of  Personnel  Functions 

It  is  obvious  that  a  software  design  which  follows  clear  functional 
objectives,  facilitates  a  corresponding  division  of  personnel  functions  and 
responsibilities  as  well.  It  makes  it  easier  for  management  to  define 
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specific  rules,  to  train  for  them,  and  to  maintain  supervisory  control  over 
both,  personnel  and  the  system. 

In  cases  where  a  finer  subdivision  of  functions  is  desired,  the  inherent 
capability  of  Logical  Table  processing  readily  allows  that  'fine  tuning'  of 
functions.  For  example,  suppose  that  the  (somewhat  dangerous)  DELETE  func¬ 
tion  for  deleting  a  whole  airfield  record  should  be  safeguarded  and  performed 
only  by  one  or  a  few  specially  trained  persons.  The  system  design  allows 
this  special  case  to  be  readily  implemented.  All  that  is  required  is  a  simple 
expansion  of  the  present  password  capability  of  correlating  'password/geo-id' 
to  one  of  correlating  'password/geo-id/transaction ' —in  our  example  the  'trans¬ 
action'  being  the  DELETE  command. 

3.3.4  Function  Scheduling 

In  a  similar  way  priority  and  scheduling  problems  can  effectively  be 
implemented.  Since  date  and  time  information  is  always  available  to  the 
system,  a  'password/geo-id/transaction/time-range '  correlation  could  be 
postulated  as  well,  to  restrict  the  access  for  certain  transactions  and  persons 
to  certain  hours  of  the  day,  thus  putting  a  time  lock  on  the  system  as  whether 
it  were  guarded  like  a  bank  vault. 

This  time- lock  capability,  by  the  way,  need  not  be  limited  to  the  pur¬ 
pose  of  assuring  greater  internal  security  (no  'unwitnessed'  critical  trans¬ 
actions  during  unusual  hours) .  It  could  also  be  used  in  the  reverse  for  the 
purpose  of  excluding  certain  transactions  from  being  run  during  regular 
hours.  This  could  apply  to  lengthy  load  operations  or  certain  application 
programs  in  order  to  safeguard  fast  turn  arounds  of  on-line  operations  during 
the  main  shift  hours. 

The  chosen  software  structure  and  the  implemented  capabilities  thus 
provide  a  wide  range  of  effective  management  controls  for  both  system  and 
personnel  functions.  Their  number  of  combinations  is  only  limited  by  ideas. 
They  can  readily  adjust  to  any  level  of  desired  complexity.  The  negligent 
implementation  costs  encourage  experimentation  with  the  possible  result  that 
in  successive  adjustments  a  close-to-optimum  division  of  labor  and  system 
functions  can  be  found  for  maximum  payoff  and  user  satisfaction. 
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3 . 4  Subsystem  Software  Functions 

The  software  developments  had  to  achieve  a  major  transition  from  a  pre¬ 
viously  batch  oriented  card  processing  system  to  an  on-line  retrieval  and 
update  system  that  permits  interactive  dialogs  between  users  and  the  computer 
for  an  efficient,  up-to-date  maintenance  of  the  AAFIF  data  base.  To  make  a 
major  progress  in  the  implementation  of  automatic  system  functions,  a  con¬ 
siderable  upgrading  of  the  built-in  machine  intelligence  had  to  be  accom¬ 
plished  in  order  to  supervise  the  on-line  procedures  for  correctness  in  both 
form  and  information  content.  As  a  result,  the  AAFIF  data  base  can  be 
expected  to  become  much  'cleaner'  in  the  future.  The  immediacy  of  computer 
responses  towards  wrong  or  format  incorrect  inputs  tends  to  make  the  manual 
operations  less  critical,  thereby  speeding  up  and  simplifying  the  update 
process . 

In  addition  to  the  on-line  capabilities,  a  number  of  batch-oriented 
processing  functions  had  to  be  implemented  for  system  loading  and  maintenance, 
and  for  the  generation  of  special  outputs  such  as  reports  and  magnetic  tapes 
(Application  Programs) . 

3.4.1  The  Air  Facilities  On-Line  System 

The  on-line  Retrieval  and  Update  capability  of  the  Air  Facilities  Sub¬ 
system  employs  several  software  modules  and  series  of  tables  with  software 
characteristics  that  perform  complex  functions  in  a  very  straight  forward  and 
simple  to  use  manner.  The  implementation  of  important  software  functions  and 
their  associated  data  in  table  form  enables  the  user  to  maintain,  to  expand, 
and  if  necessary,  to  restructure  the  system  through  data  entries.  By  avoid¬ 
ing  software  changes  and  reprogramming  efforts  in  areas  most  vital  to  the 
user  a  high  degree  of  vendor  independence  and  system  flexibility  has  been 
achieved.  This  adaptability  to  changed  situations  will  make  the  system  more 
responsive  to  the  changing  needs  of  ADA,  and  is  bound  to  save  considerable 
amounts  of  cost  and  time  in  the  future. 


Two  basic  types  of  displays  are  used  to  attain  smooth  interfaces 
between  the  user  and  the  computer: 

•  Menu-oriented  displays  that  permit  the  user  to 
select  from  a  variety  of  possible  options 

•  Retrieval  displays  for  updating  data  elements 
of  any  record  in  the  system 

3 . 4 . 1 . 1  Menu-Oriented  Displays 

The  menu-oriented  displays  provide  the  interfaces  for  the  various 
processing  functions  such  as  log-on,  password  processing,  updates,  Boolean 
searches,  and  so  on.  They  allow  a  menu-oriented  dialog  that  guides  both 
user  and  system  to  any  one  of  the  required  display  data  input,  processing, 
and  error  checking  routines.  They  perform  this  task  in  a  systematic  and 
safe  manner  that  avoids  operator  confusion  and  system  crashes. 

The  implemented  display  menus  of  the  pilot  (Phase  I)  system  have  in¬ 
formation  in  great  detail  so  that  it  is  possible  for  an  untrained  person 
to  become  familiar  with  all  operations  just  by  testing  the  various  options 
presented  to  him.  In  fact,  the  system  can  be  regarded  in  this  version  as  a 
very  patient  'teaching  machine'  that  is  instructive,  responsive  —  as  well 
as  tolerant  against  'dumb'  user  mistakes.  (The  latter  will  trigger  feed¬ 
backs  with  requests  or  suggestions  for  proper  input  alternatives) .  If  de¬ 
sired,  the  inherent  flexibility  of  our  table  approach  facilitates  the 
establishment  of  a  very  'terse'  arid  to-the-point  menu  sequence  as  well.  Such 
a  condensed  and  time-saving  version  could  readily  be  implemented  during 
Phase  II  for  those  repetitive  operations  that  have  to  be  performed  frequently 
by  experienced  personnel. 
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3. 4. 1.2  Retrieval  Displays 

The  retrieval  displays  present  small  sections  of  the  data  base  informa¬ 
tion  for  on-line  review  and  update  procedures.  As  the  accompanying  figure 
shows/  the  display  is  graphically  divided  into  three  areas: 

(1)  The  Display  Header  with  essential  record  information 

(WAC,  Inst.  No.,  Country  Code/Province),  geographical  identifier, 
date  and  time.  The  Display  Header  stays  the  same 
during  the  update  transactions  of  an  air  field  (which 
might  encompass  several  display  ’pages'). 

(2)  The  main  display  portion  depicting  a  section  or  'page1 
of  the  current  data  base  information  with  identifying 
labels,  and  a  data  entry  field  for  new  inputs  or  updates. 

(3)  A  communications  area  for  the  display  of  error  messages 
and  the  input  of  program  control  decisions.  Whenever  an 
input  error  is  encountered  while  updating  the  main  section 
(2) ,  this  communications  area  will  be  displayed  with 
appropriately  selected  error  messages  and  response  options. 

3.4.2  System  Tables 

Four  types  of  tables  are  involved  in  the  processing  of  the  retrieval 
displays: 


•  Label  Tables,  containing  data  base  element 
identification  codes,  element  descriptions 
(labels),  display  processing  instructions, 
references  and  program  control  information  for 
required  format  and  logical  checks. 

•  Format  Check  Tables,  that  specify  in  detail  which 
specific  input  data  or  type  of  input  data,  is  ac¬ 
ceptable  as  'new'  or  'update'  information.  The 
appropriate  format  check  table  will  be  evaluated 
immediately  after  each  input  has  been  completed. 

In  case  of  a  format  failure,  the  cursor  will  jump 
into  the  communications  area  (3) ,  with  appropriate 
messages  and  response  options  displayed  for 
remedial  actions. 


Logical  Check  Tables.  The  format-correct  update 
information  for  an  air  field  will  be  held  in  a 
temporary  SAVE  file  until  all  inputs  for  that 


air  field  have  been  completed.  They  are  then 
made  subject  to  logical  checks  that  test  for 
valid  interrelations  between  various  data  base 
elements . 

There  are  many  instances  where  a  format-correct 
input  still  could  be  'false' —  or  make  no  sense  — 
if  correlated  with  other  information  for  that 
air  field.  This  correlation  is  performed  by  the 
Logical  Check  Tables.  Their  extensive  use  can 
make  the  system  quite  'intelligent'  by  constantly 
applying  supervisory  functions  to  the  actions  of 
a  less  knowledgeable  —  or  less  alert  —  group  of 
users.  In  cases  where,  due  to  complexity,  certain 
inputs  should  be  made  by  the  computer  itself 
(rather  than  by  the  human  operator) ,  the  SET 
command  of  the  Logical  Tables  implements  these 
inputs  correctly  and  automatically. 

•  Communication  Tables  of  the  menu-oriented  display 
type,  discussed  earlier.  In  case  of  an  input 
error,  or  the  completion  of  a  page  update,  the 
appropriate  communication  display  with  messages 
and  response  processing  options  will  be  presented 
to  the  user  for  his  decision  on  how  to  proceed. 

Although  the  mentioned  tables  describe  and  determine  the  system 
behavior  in  its  most  important  aspects,  they  remain  strictly  data  driven 
Any  changes,  deletions,  or  expansions  of  processing  functions  are  readily 
implemented.  They  do  not  require  reprogramming  and  recompilation  efforts 
with  associated  storage,  linkage,  overlay,  and  other  inherent  system 
problems  that  can  make  the  task  of  change-implementation  a  time  consuming, 
difficult,  and  --  for  a  system  that  must  remain  operational  —  outright 
dangerous  one.  In  contrast,  a  few  'systems  people',  knowledgeable  in  the 
workings  of  these  tables,  can  now  determine  and  'massage'  the  system 
functions  to  almost  any  desired  degree  of  detail  and  complexity  with  rela¬ 
tive  ease  and  without  any  outside  assistance.  Only  in  the  few  cases  where 
desired  changes  of  communication  tables  entail  changes  of  on-line  selected 
processing  options  as  well,  programming  efforts  may  be  required  to  accomo¬ 
date  the  altered  processing  sequences. 


3.4.3  Label  Book  Tables 


An  important  effort  of  the  project  was  the  reformatting  of  the  AAFIF, 
residing  on  the  UNIVAC  1108,  into  an  acceptable  data  base  structure.  This 
effort  resulted  in  a  document  titled  "System  Design  Plan  and  Specification 
for  AAIPS;  Appendix  C,  AAFIF  Data  Base  Definition"  ('Label  Book').  Its  major 
feature  was  the  establishment  of  a  unique,  four-character,  retrieval  code 
for  each  data  element  of  an  airfield  record,  and  the  accompanying  descriptive 
element  name  (label). 

The  Label  Book  contains  the  identifying  labels  for  each  of  the  over  600 
data  elements  of  an  airfield  record.  The  subsequently  generated  tables  con¬ 
tain  this  information  on  a  page-by-page  basis.  Those  pages  are  stored  only 
once  in  the  system  to  be  used  for  all  records  (airfields).  However,  a  page 
will  always  be  displayed  on  the  Datagraphix  terminal  along  with  the  corre¬ 
sponding  information  of  a  particular  airfield  retrieved  from  the  data  base. 
With  this  approach  a  specific  label  table  has  to  be  brought  into  the  main 
memory  for  every  display  page  to  be  processed.  The  table  information  is  then 
combined  on  the  screen  with  pertinent  airfield  data  for  the  ease  of  human 
review  and  processing  (see  the  previously  shown  Figure  3-5)  . 

3. 4. 3.1  Processing  Functions 

Since  the  loading  of  label  information  is  a  standard  routine  with  this 
concept,  it  had  been  decided  to  include  also  important  program  selection, 
display  control,  edit,  multiple  and  text  processing  instructions  in  the 
table  design.  In  this  way  a  data-driven  capability  of  function  selections 
has  been  achieved  that  allows  specific  and  detailed  control  down  to  the 
element  level  of  the  data  base.  With  that,  ADA's  system  personnel  has  a 
powerful  tool  at  hand  to  specify  and  to  remold  the  behavior  of  the  Air 
Facilities  system.  They  can  accomplish  this  by  just  making  data  changes  to 
the  appropriate  table  entries  and  by  reloading  them  into  the  system. 

3. 4. 3. 2  Samples  of  Label  Tables 

The  program  LDISPLAY  produces  headers  and  tab  settings  for  the  initial 
on-screen  generation  of  a  Label  Table.  (See  enclosed  sample  pag^s.) 


29 


X) 

■* 

1 

*  * 

*  « 

2 

Z  Z  Z 

•* 

♦ 

* 

* 

■# 

2 

ru 

• 

X 

1 

*— 

>— 

^  i— 

L— 

»**■ 

►— 

+r- 

i/i 

CD 

/-> 

1 

O 

2: 

O  2 

2 

© 

ru 

ru 

2 

© 

ru 

O 

2 

1 

X 

Li. 

LL 

X  li¬ 

2 

U. 

Li- 

li¬ 

lx 

U. 

r— * 

1 

CD 

Z 

z 

es  2 

2 

CD 

CD 

es 

2 

CD 

3- 

ru 

-1 

1 

ru 

ru  — « 

— 

— * 

— 

r-o 

m 

— < 

f*“*  <■  a  n 


rv  <r  •—  u 


x,  h- 


—  3  i 

ru  co  i 


ii 

x  •  II 

O  <  c  II 
ru  z  z  ii 


a  — 

—  to 


‘i  ii 

•  II 


cr 

►— 

LU 


/ 


X'  ru 

i  i 


or  a 


or  cr  >21 


CJ 

II 

*n 

NO 

•”* 

K. 

ru 

ru 

LT- 

ru 

X 

fO 

fO 

fO 

1*0 

sC 

X 

1 

1 

—* 

co 

X 

1 

CD 

CO 

2 

2 

co 

1 

— 

< 

2 

> — < 

2 

X 

1 

H— 

-J 

2 

/ — 

CJ 

3 

1 

< 

CJ 

— * 

> — 

X 

y- 

2 

1 

2 

Ll 

r— 

c 

X 

r— 

X 

y. 

< 

1 

or 

CJ 

<1 

2 

X 

^v 

' — 

CO 

< 

r 

1 

3 

< 

Ll* 

2 

y 

H* 

2 

CO 

<3 

X 

X 

2 

1 

X 

~3» 

co 

cr 

3 

X 

'x' 

”V» 

2 

r  r> 

CJ 

1 

2 

2 

X 

u 

-L 

or 

a- 

•c 

X 

X 

—1 

1 

HH 

X 

2 

LL 

2 

o: 

<t 

2 

Z 

X 

CJ 

X 

u*-; 

t — 

X 

1 

CJ 

2 

2 

• — 

S—y 

X. 

3 

Z 

3 

X 

r> 

2 

c 

X- 

1 

-J 

•iJ 

2 

r— 

■ — 4 

V 

X 

X’ 

3 

— - 

X 

CO 

>- 

y 

2 

< 

1 

< 

— ' 

_ 1 

X" 

U— 

— 

*v 

•X 

2 

-1 

2 

h- 

2 

y. 

2 

X 

_J 

1 

x 

X 

2 

►— 

< 

h- 

CO 

3 

CD 

-y 

V 

X 

c 

2' 

< 

CO 

_ _ 

1 

Ll 

u. 

o 

rc 

CO 

— ' 

-L 

CO 

X 

•— 

< 

7 

C 

2 

q 

>— * 

X 

CJ 

2 

2 

. 

X 

X 

1 

2 

z 

•— 1 

“T 

— i 

or 

2 

JL- 

f- 

<s 

3' 

-J 

2 

X 

"V 

3 

- - 

X 

2 

2 

3 

►— t 

z. 

1 — 

2 

*7 

1 

LL 

< 

<T 

>- 

X 

c 

2 

•— 

c 

3 

2 

»— * 

X 

CO 

»— 

2 

_ ' 

2 

2 

2 

1“ 

2 

y. 

2 

< 

1 

CD 

CO 

XJ 

> 

3 

< 

i 

3 

r— 

0: 

2 

y. 

X 

X 

< 

X 

2' 

»— 

c 

3 

1 

X 

-J 

— 

> 

c 

y; 

a- 

2 

2 

_ 

2 

X 

X 

X 

r- 

X 

1 

>~ 

2 

»— 

2 

2 

CJ 

< 

X 

to 

3 

CJ 

2 

X 

2 

> 

X 

Z 

*  r 

X 

CO 

•d 

>- 

»— 

1 

*— 

2 

< 

_ * 

_J 

X 

X. 

2 

XI 

2 

X 

r— 

-J 

2 

i 

u 

> 

X 

X 

rv 

1 

— 

X 

2 

-Ll 

LU 

— 

DC 

3 

3 

X; 

»— 

3 

X 

ji 

S 

<. 

3 

x 

2 

3 

xJ 

1 

_ i 

— • 

2. 

*— 1 1 

*■« 

LU 

C 

T~ 

2 

X 

CO 

X 

c 

— * 

►— 

— 

*— 

— 

►- 

— 

X 

“V 

<3 

f  r 

1 

*— > 

LL 

xJ 

Ll 

LL 

2 

Ct 

r— 

3 

X 

2 

3 

2 

3 

2 

2 

n 

»— 

X 

X1 

X 

1 

U 

Cl 

*— 

X 

2r 

CS 

*— • 

<c 

2 

<r 

X 

X 

CD 

X 

X 

CO 

CO 

GO 

y. 

y. 

y 

r- 

s. 

3 

y 

►— 

►— 

-1 

1 

< 

—I 

X 

— « 

>— < 

< 

uJ 

O 

CD 

C 

3 

\ 

X 

»— < 

co 

co 

CO 

y> 

co 

CO 

•x 

3 

c 

~ 

<1 

<r 

1 

Ll 

< I 

c 

<3 

<s 

2 

o- 

X 

2 

HH 

2 

<r 

2 

< 

<j 

< 

<3 

< 

<r 

< 

CJ 

*» 

n-i 

© 

3* 

Ll1 

1 

\ 

O. 

nr, 

X 

X 

a 

© 

ru 

cr 

ITi 

vC 

CX. 

cr 

2. 

ru 

ND 

in 

X 

1 

LL 

© 

2 

© 

© 

© 

© 

© 

o 

© 

«-• 

• 

»— 

*— 

XJ 

X’ 

ru 

ru 

ru 

ru 

XJ 

ru 

CD 

1 

CD 

Ll 

Ll 

Ll 

Ll 

Ll 

LL 

Ll 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

lL 

X 

X 

X 

CJ 

1 

CD 

CD 

CD 

CD 

CD 

CD 

CD 

CD 

CD 

CD 

CD 

CD 

3 

CD 

CD 

CD 

& 

cD 

CD 

cr 

»  r 

3 

cr- 

3 

3 

3 

3 

Header 

produced  by  LDISPLAY 


v 

On-Screen  Input 


30 


- 


*t?0d9  1  £  ‘ISVTJ  JdS  U  d  r  1 1  H39  Ait'UJVd  b?d9 

*  b  u  d  9  I  t;  3U03  Odt)  6?d9 


X  (IN  I  <?  I  3  *0N  1  IlMf!  H  V  H  3  (  3  H'V  1 )  .U  VU  ifHWJH  3(li)3 

*‘3i)3  3  »IVI  HVi  S  XVW  ilnlt;  *HN  MljM 

(7?  it!  d  d  I  ?  1)2  hi  Wl  hl*'l>»V'l  i  l 


*  * 

►— 

2. 


*  * 


003303000  3  0  0  O 

JZZ2Z222ZZ2Z  U. 

Z22ZZ22Z2222  (Z 

r\j  ^  ^  -o  rr  v-,  v-,  fr,  ^ 


•*  I 

•  xr  i  x  x  x  x  x  cc  o 

troi  oooooo  o 

C  Z  I  Z  Z  Z  Z  Z  Z  lx 

_J  —  I  Z  Z  Z  Z  Z  Z  12) 


rv 

x 


ii 

x  •  II 

<  :  ii 

£  2  II 


y  Z 


O 

2 


< 

CJ 


X 

*n 


\n 

y. 


'S  <3 
< 


y 

'j. 


_) 

o 

y; 

c/r 


<  x  z  c.'  i  i  £ 


—  ic 
c  <r 


>-  >- 

<  < 

i  2. 


>- 

< 


'_)  'w  'J  U  (J  12  CJ  'sJ  LJ  CJ  12 

2  \  SNNS\N.\\\\N_' 

x«rcc<c<<  <  <  <  c  <j 

2<C<<<<<<<<<<L 

x2xLT2:22rzlJ2..iC 


\  o:  >:  * 


PV  ^  c  ^ 


z  z 


z  z 


<  <■ 

'w  Z  LJ  Cl  > 

1  1  \  <  <  —  *— > 
—  *—  ^  i  i  u  -  xcrixcr^a:i2>> 
ori  5iC<^2\s<JWZ<< 

c.  a.  ►-  <  >»->z<ca.—  cizz 
x  o  7  c.  - 

C  0003  ~  — 

zzzzzz  z  z  z  z  z  z  z  zzzz 
zzzzzzzzzzzzzzzzz 


Z  12 


X 

r^. 


x> 

CO 


—  -J 


lx  _  _  y 


I  Z  Z  _j 

—  —  <r  ^  ~  _ 

i  r  :r  >-  z  i 

r 

Z.  U.  -2  _J  ►—  •—  r— 

— ■  —  -J  -J  O  Z  Z  I 

3  x1  uJ  x  <  C  <  — 

r-  r-  -  'J  L  2  12 


O:  Lx  I  s-fo^c/vC^i 
<—  Z  I  3.00000000 
-i-CI  ZQ-3.Q.G.3  Cl  Cl  3. 
3:  U  I  N222222Z2 


32 


/ 


I 


>C 

« 

♦  1 

*  ■*  * 

«  « 

*  * 

*  2  2 

■* 

*  *  2  •* 

*  *  <*  * 

♦  2 

rv 

• 

x  1 

+>*. 

OJ 

ip 

LS» 

X  1 

ru 

o 

ru 

<v 

X 

2  1 

Ll. 

X 

U. 

— i 

*-  1 

O 

<3 

LS 

3i 

ru 

_) 

1 

p 

— < 

P 

ru 

ru 

ru 

ru 

ru 

X  H 


< 

ru 

it 

ru 

n 

»<r> 

it 

ru 

< 

it 

a 

►- 

M 

o 

i 

a 

CC 

i 

♦ 

IP 


X 


*  *  *  2  2 

N  CC  O'  C  r- 

r-l  Oj  f\j 

i  or  2  a:  i 

<  <L  <S  C  <3 


II 


X 

• 

II 

c:  <r 

c 

II 

ru 

a 

a 

a 

ru 

a1 

a 

a 

rv 

rv.' 

ru* 

rv 

Or 

a 

ru 

a1 

ru 

ru 

a 

a1 

a1 

a 

a 

a 

a 

ru 

ru 

ru 

ru 

ru- 

ru  51 

II 

P 

y 

p 

p 

p 

p 

p 

rp 

fp 

fy, 

ip 

fy, 

P 

fp 

p 

p 

p 

P: 

p 

p 

p 

p 

p 

p 

p 

P 

P 

P 

P 

p 

f r 

— 

II 

2 

— 1 

II 

O'  — 

II 

£ 

II 

— 

— 

— 

— 

— 1 

— 

•“ 

— * 

— 

— • 

— 

— 

— 

— 

— 1 

X 

II 

• 

< 

II 

X  z 

x 

II 

—  - 

JJ 

II 

iP 

P 

p 

— 

-* 

- 

•y, 

•y, 

p 

IT 

■y 

p 

ru 

tP 

hr 

— 

iT 

ry 

3J 

p 

ai 

tP 

1 

<— N 

1 

— 

— 

x 

x 

x 

x 

x 

x 

»— H 

— . 

< - s 

r~^ 

1 

2 

2 

2 

x 

2 

X 

z. 

2 

x 

Cj 

x 

x 

x 

X 

1 

aj 

LL' 

-L 

_L' 

Jj 

'J J 

X 

x 

x 

2 

v 

X 

2 

2 

1 

X 

X 

-L 

J_ 

•L 

x 

OJ 

1 

? 

'i 

■?. 

x 

•* 

■§ 

?. 

:Z 

1 

x 

x 

x 

x 

x 

x 

x 

x 

. — ’ 

— < 

>— • 

— 

>— « 

1 

_ : 

/l 

■X 

_ ; 

_ 

_J 

_ 1 

_ > 

X 

z 

x 

X 

X 

X 

1 

w 

JJ 

w/ 

>— ■ 

— ' 

W/ 

' — ' 

' — 

w 

w 

W ' 

> — - 

t 

1 

•— 

*_n 

— s 

1 

— 

x 

r. 

•LL 

1 

JJ 

CP 

•-H 

CJ 

CJ> 

X 

r— 

X 

x 

1 

< 

_ ! 

X 

— 

c 

>- 

> 

J. 

<L 

*— 

X 

d 

— 

x 

f 

LL 

—'1 

x 

X 

>- 

>- 

— 

XJ 

Ll 

•  fN 

-J 

»  r 

X 

X 

•  r> 

-J 

y 

< 

1 

*v 

-'*". 

c. 

<. 

r-. 

*— 

— 

*— 

! — 

_ . 

cL 

'X 

— * 

r— 

X 

z 

X 

W 

*U 

_ 1 

1 

x 

JJ 

x 

x 

UJ 

X' 

— > 

_ .' 

CP 

x 

LJ 

w 

X 

CP 

_ _ 

X 

X 

• 

w 

1 

-  • 

:  • 

x 

<■ 

X' 

X 

•— 

> 

x 

CP 

_ , 

X 

X 

>- 

T 

•f 

- J 

X* 

_ ‘ 

„  1 

I 

-L 

x 

— 

< 

— 

X 

‘J; 

X 

— 

— 

X 

cc 

X 

— 

*— 

n 

1 

X 

JJ 

'  ' 

■  ■ 

— 

a. 

<r 

X 

_J 

— 

X 

— 

X 

y 

X 

cc 

t  ' 

T 

— 

~ 

*1 

x 

cr 

< 

< 

1 

2 

X 

JJ 

i— 

< 

< 

cc 

X 

■ — 

— 

x 

X 

X 

»r 

•x 

<3 

X 

— 

— 

X 

_ 

X 

x 

1 

JT 

X 

»— 

x 

< 

<L 

r— 

> 

z 

►— 

/. 

X 

J: 

X 

■ — 

X 

— 

y. 

X 

X 

X 

*— • 

1 

X 

r- 

*— 

LL 

x 

•w 

-J 

X 

~ 

JL 

> 

:t 

cr 

X 

V 

X 

.  ;  t 

> 

X 

X 

r 

x 

»— 

1 

'J 

— > 

2 

x 

'• 

x 

x 

Cl 

> 

►— 

7 

r 

►— 

•  r 

<r 

2> 

L_‘ 

a. 

Ll 

u. 

X 

<1 

X 

<. 

-v 

X 

X 

X 

X 

X 

< 

2T 

1 

>- 

w*_ 

aJ 

— 

x 

X 

X 

♦— 

cc 

■Si 

X' 

LJ 

?< 

►— I 

jj 

> 

> 

X 

X 

X 

X 

X 

X 

X 

> 

>» 

X 

X 

1 

<. 

-r. 

-J 

CP 

cc 

JJ 

< 

-L, 

a 

_ ,• 

_l 

U. 

X 

<i 

u_ 

X 

C 

X 

< 

uc 

< 

x 

<r 

X* 

x 

x 

X 

<r 

cr 

2. 

1 

1 

x 

> 

>- 

>* 

>- 

V 

>- 

>- 

>- 

>- 

>- 

>- 

>- 

>- 

>- 

>- 

>- 

>- 

>- 

>- 

>- 

>- 

>- 

>- 

>- 

>- 

V 

>- 

>- 

>- 

i 

1 

-i 

? 

n 

e. 

£ 

*» 

.•» 

2 

s. 

?: 

2. 

J 

s 

y 

L 

«/■ 

LL. 

1 

~y 

X 

J: 

— 

rv 

"V 

Cc 

-v 

- 

>v 

“W 

> 

x 

*y 

.T: 

X 

X 

X 

rv 

X 

X 

X 

X 

X 

X 

X 

X 

x 

*v 

1 

, 

ru 

p 

p. 

cr 

a 

p 

i  r> 

vC 

X 

- 

■X 

ru 

p 

=T 

wr 

>c 

X 

X 

o 

— 

x 

1 

0: 

o 

O 

X- 

o 

o 

o 

— 

— 

— < 

*-> 

•— 

*— 

ru 

"U 

OJ 

ru 

ru 

a 

•\i 

ai 

ru 

ru 

p 

ll 

x 

1 

< 

CL 

rv 

2r 

V 

x 

fiE 

»v 

x 

V 

'-V' 

X’ 

y- 

"V 

•a: 

X 

X 

rv 

X 

X 

X 

X 

rv 

X 

X 

«—  X 

o 

1 

< 

c 

< 

< 

< 

<r 

■d 

< 

d 

< 

<£ 

<r 

< 

<3 

< 

-3 

< 

<3 

< 

<: 

<3 

< 

<3 

< 

<. 

<■ 

<3 

<3 

<3 

33 


/  : 


Nt?039  I  £  KSV'IJ  33S  S  A  MM  t/£faV 

N  848  l-  8£  S'  MHVrt  IM  SAMrt  *£*IV 

♦  faOdS  l  fa  c'f  l  £  faQvTl)  CHS  AMrt  ££faV 

Ne^faV  I  <-£  1  l  ({liv'd  T  til  i;  llltin  HltVH.Sdc'V  A  toil  l£ilV 


3 . 4 . 3 . 3  Entry  and  Load  Programs 


LDISPLAY  -  Program  that  produces  headers  and  tab  settings  for  the 
on-screen  generation  of  Label  Book  pages. 

PLABL  -  Program  for  printing  out  the  Label  Book  (currently  82  pages) . 

CLBL  -  Program  to  process  all  label  pages  by  devising  and  making 

computed  inputs  to  each  table,  by  creating  multiple  displays 
from  oversize  pages,  and  by  producing  a  file  'INLABEL*  which 
is  used  for  loading  the  processed  tables  to  INFOS. 

The  contents  of  the  Label  Book  Tables  control  and  generate  programmed 
functions  as  if  those  functions  were  implemented  through  specific  software 
routines. 


| 

1 


3. 4. 3. 4  Table  Column  Definitions 


The  columns  of  the  table  (one  16  bit  computer  word  per  column)  are 
used  as  follows: 


Col.  1-2: 
Col.  3-17: 


Col.  18: 


Col.  19: 


Retrieval  code  for  data  element. 

Description  (identifying  label  of  data 
element) 

Number  of  characters  to  be  displayed 
(left  adjusted) .  If  right-adjustment 
is  desired,  e.g.  for  numerical  values, 
the  letter ‘R’  will  be  added  in  the  fourth 
input  position  of  column  18.  The  maxi¬ 
mum  display  width  for  a  text  item  is  38 
characters.  (For  larger  text  fields  see 
the  following  two  items) . 

A  positive  number  indicates  the  start 
position  (or  element-identification  number) 
of  a  multiple  of  which  the  element  in 
question  is  a  member.  Since  multiples 
should  always  be  presented  together  as  a 
group  (in  order  to  avoid  wrong  data  inter¬ 
pretations  or  faulty  updates)  the  proper 
entry  in  this  position  will  assure  correct 
display  processing  of  those  multiples. 

A  negative  number  (-1)  in  this  column 
means  that  the  data  base  element  in 
question  is  a  text  field.  The  information 
will  not  be  displayed  (due  to  space 
problems  that  otherwise  would  be  encountered 


34 


with  the  regular  retrieval  display) .  The 
negative  number  merely  causes  a  'TEXT' 
indication  to  be  shown.  At  the  same  time, 
however,  text  processing  routines  for  these 
data  fields  are  made  available  in  separate 
displays  if  the  user  wishes  to  review  or 
update  such  textual  information. 

Those  data  fields  that  carry  a  (-2)  in  this  column 
are  sufficiently  short  that  they  could  be  displayed 
on  the  regular  retrieval  displays  --  using  both 
'CURRENT'  and  'NEW'  columns  (desirable  Phase  II 
extension).  The  retrieval  display  would  show 
the  contents  of  this  field.  However,  updating 
(i.e.  the  entering  of  'NEW'  information)  would 
require  a  switch  to  tht?  regular  text  processing 
display. 

A  zero  or  blank  entry  in  Column  19  indicates 
a  regular,  single  data  element. 

Col.  20:  This  column  is  evaluated  only  in  conjunction 

with  Column  19.  If  Column  19  is  a  positive 
number  (indicating  an  element  that  belongs  to  a 
multiple  group)  then  the  number  in  Column  20 
determines  the  maximum  number  of  multiples  al¬ 
lowed. 

If  Column  19  is  a  negative  number  (indicating 
a  text  field)  then  the  number  in  Column  20 
describes  the  maximum  number  of  characters 
allowed  in  this  text  field. 

Col.  21:  This  column  is  used  for  line  display  control 

purposes.  The  first  character  is  a  line  space 
control  number  (S)  that  can  be  any  number  from 
'0'  or  'space'  to  '9'.  The  second  character  of 
this  column  is  the  display  character  (C)  which 
is  to  be  used  repetitively  to  form  a  graphic 
line.  In  case  of  a  'O'  or  'space',  the  next 
line  will  be  used  for  displaying  a  subsequent 
entry.  If  S  is  between  ’ 1*  and  '8',  the 
next  entry  line  will  be  preceded  by  1  through 
8  line  spacings.  The  last  of  these  inserted 
line  spacings  will  carry  a  character  symbol 
(specified  in  C)  repetitively.  This  forms  a 
graph  line  consisting  of  that  symbol. 

In  the  case  of  S=9,  the  data  entries  are  followed 
by  a  line  spacing,  again,  using  the  symbol,  specified 
in  C. 
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Exampl e :  In  order  to  highlight  and  to  separate 
a  multiple  group  from  single  element  items,  a 
column  entry  of  '1-'  for  the  first  item  of  the 
multiple  group  and  a  column  entry  of  '9-'  for  the 
last  entry  of  that  multiple  would  achieve  the 
desired  display  effect. 

Col. 

20 

SC 

SINGLE  DATA  BASE  ELEMENT  XXX 

ANOTHER  SINGLE  ELEMENT  XXX 


2 

FIRST 

ELEMENT 

OF  A 

MULTIPLE 

XXX 

1- 

2 

OTHER 

ELEMENT 

OF  A 

MULTIPLE 

XXX 

2 

OTHER 

ELEMENT 

OF  A 

MULTIPLE 

XXX 

2 

LAST  ELEMENT  OF  A  MULTIPLE 

XXX 

9- 

SINGLE  DATA  BASE  ELEMENT  XXX 


The  proper  length  of  the  inserted  symbol  line 
is  computed  and  may  vary  from  one  display  page 
to  another. 

22/23:  Tab  settings  for  the  display  start  positions 

of  label  and  data  base  information.  These  tab 
settings  are  computed  to  achieve  a  pleasant  display 
arrangement,  taking  into  consideration  the 
maximum  field  width  of  data  base  elements  in  a 
page,  left  or  right  adjustment  of  th"  ^ield,  and 
a  pertinent  centering  algorithm. 


In  special  cases,  manually  inserted  tab  settings 
may  be  used.  This  has  the  effect  of  overriding 
the  computed  values. 


Col.  24: 


This  column  is  used  for  edit  processing 
control  purposes.  The  control  numbers 
must  be  chosen  with  great  care  since  they 
determine  not  only  the  extent  of  format 
and  logical  checks  for  a  given  data  element, 
but  also  the  required  edit  tables  that  must 
be  accessible  by  the  system.  All  specified 
edit  tables  must  be  internally  correct  and 
completely  loaded  without  exception. 
Otherwise,  serious  processing  and  system 
malfunctions  are  to  be  expected. 


Edit  Program  Control  Number 

T 


L 

Format  Checks 

Loqical  Checks 

(Blank) 

Own  Table 

No  Logical  Checks  Required 

1 

Different  Table 

No  Logical  Checks  Required 

2 

Own  Table 

Own  Table 

3 

Own  Table 

Different  Table 

(4) 

Not 

Used 

5 

Different  Table 

Different  Table 

*  Retrieval  code  of  'different'  table  must 
be  listed  in  Columns  25,  26 


As  the  above  outline  shows,  only  the  numbers 
'O'  or  'blank'  and  1,  2,  3  and  5  may  currently 
be  used  as  edit  controls.  They  indicate 
which  edit  tables  are  to  be  retrieved  by  the 
system  to  perform  the  required  edit  checks. 

In  the  case  of  even  control  numbers  only 
'Own  Tables'  are  involved,  meaning  that  the 
name  of  the  specific  format  or  logical  table 
is  identical  with  the  element-id  listed  in 
Columns  1  and  2. 

In  the  case  of  odd  control  numbers  'Different 
Tables'  are  involved.  Their  name  is  listed 
in  Columns  25,  and  26.  It  means  that  an  edit 
table,  established  for  a  different  data  base 
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element,  can  also  be  used  for  the  element  in 
question. 

This  ’indirect  table  addressing'  feature  cuts  down 
on  data  loading  and  storage  requirements.  It  is 
of  particular  value  in  logical  checks  that  bring  an 
extraordinary  high  level  of  machine  intelligence 
to  the  problems  of  supervising  user  transactions, 
or  even  generating  these  transactions  automatically 
(computed  inputs) .  Since  logical  checks  correlate 
the  entries  of  several  data  elements,  it  is 
possible  to  refer  all  elements  involved  to  one 
'master'  table  for  testing.  In  this  way  pertinent 
logical  test  procedures  can  be  triggered  by  the  update 
of  any  one  of  these  elements  rather  than  by  the 
obvious  'main'  event  (s)  alone.  Although  the 
table  itself  may  show  a  highly  structured  process¬ 
ing  hierarchy,  the  lowliest  member  of  that  hierarchy 
can  set  off  the  required  test  processing. 

In  a  very  simple  and  straight-forward  manner  a 
systematic  and  comprehensive  multi-entry  capability 
to  complex  processing  procedures  can  thus  be 
established. 

25/26:  Table  name  (index)  of  'different'  Format  or 

Logical  Check  table  to  be  used  for  the  data 
element  in  question. 


24 

L 

25  26 

Index 

Meaning : 

1 

GF04 

Use 

FORMAT 

table  GF04 

3 

LA15 

Use 

LOGICAL  table  LAI 5 

5 

XX01 

Use 

FORMAT 

table  XX01  and 

LOGICAL  table  XX01 


The  entry  NFMT  (no  format)  will  be  used  for  those 
data  elements  that  have  no  edit  checks  at  all 
(e.g.  fields  with  computed  inputs). 
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Last  Entry:  *  -  Element  used  for  U.S.  limited  data  airfields. 

N  -  Element  not  being  utilized  for  'U.S. 

Facilities'  or  'U.S.  Facilities,  except 
GF02  and  GF15'. 

While  table  space  has  been  provided  for  these 
two  items,  and  pertinent  entries  have  already 
been  made,  the  processing  consequences  need  to  be 
defined  in  greater  detail  and  program  implemen¬ 
tations  have  to  be  made  in  Phase  II.  During 
the  loading  process  the  last  entry  will  be  com¬ 
bined  with  the  control  information  in  Column  24 
(+  50  for  '*' ,  +  60  for  'N') . 

The  columns  18,  19,  20,  22,  and  23  will  be  converted  into  integers 
when  loaded  to  the  system.  (These  columns  show  a  double_underlining  of 
the  table  header,  produced  by  the  program  LDISPLAY.)  Although  the  ASCII 
input  column  provides  more  than  two  character  positions  per  column,  the 
final  (converted)  column  will  only  be  of  16-bit  length  (one  computer  word) 
when  loaded  to  the  system. 


3. 4. 3.5  Page  Header  Line 

The  82  Label  Tables,  created  as  outlined  in  the  previous  paragraphs, 
also  contain  a  table  header  (zero  line)  that  describes  the  sub-category. 
For  example: 


Columns  13  17 

/GF/FACILITY  GENERAL  INFORMATION 


While  columns  18  through  26  need  no  manual  entries,  they  are  used  nevertheless 
for  inputs  with  special  meanings,  computed  and  inserted  by  the  load  program. 
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3.4. 3.6  Table  Loading 

The  load  program  for  Label  Tables  CRTLBL  performs  the  discussed  integer 
conversion,  computed  inputs  for  program  and  display  controls,  and  table 
size  adjustments  with  the  creation  of  continuation  tables  where  necessary. 

It  produces  a  load  file  'INLABEL'  for  the  loading  of  each  processed  table 
to  INFOS.  This  enables  the  on-line  processing  software  later  on  to  retrieve 
from  INFOS  individual  tables  by  placing  it  into  a  common  storage  area: 

COMMON  /LTABS/  LABLX (624) ,  LEDX  (330) .  By  equivalencing  LABLX  to 

LABL (26 , 0 : 23)  ,  the  26x24  dimensioned  table  (including  the  zero  or  header 

line)  can  be  accessed  in  the  desired  form  using  column  and  row  indices. 


3. 4. 3. 7  Computed  Header  Line  Columns 

Columns  18  through  26  of  the  zero  or  header  line  are  used  by  the 
loading  program  that  creates  INLABEL.  The  computed  and  inserted  data  have 
the  following  meaning: 


Col.  18: 


TAB  setting  to  center  the  display. 


Col.  19: 


Unused. 


Col.  20:  Total  number  of  elements  (rows)  in  the 

original  Label  Table,  including  header 


or  zero  row. 

Col.  21:  Unused. 

Col.  22:  Tab  for  display  column  header  'CURRENT', 

centered  over  columnn. 

Col.  23:  Tab  for  display  column  header  'NEW', 

centered  over  column. 


<'ol .  24:  Actual  number  of  elements  in  display. 

(Tables  that  are  too  long  will  be  broken 
up  by  the  load  program  into  two  display 
tables.  Extra  lines  for  graphic  separations 
of  multiples  are  considered  also.  The  actual 
number  of  elements  describes  the  number  of  elements 
in  each  display  —  rather  than  the  total  number 
of  elements  of  the  subcategory) . 


/  w. 


Col.  25/26:  Identification  of  original  Label  Table, 
e.g.,  LAJ01  (first  table). 

3.4. 3. 8  Load  File  Sample 

On  the  following  pages  a  small  part  of  the  Load  File  INLABEL  is 
presented.  It  indicates  the  current  table  design  as  loaded  to  the  system. 


1  3 

18 

2Q 

22  23  24  26 

t - 1 

/GF/FACIL1  TY  GENERAL  I ' F  0  R f  l  A  T  ION 

1  1 
30 

1 

0 

rn  i  Mil 

30**  76  9520LA01 

GF01 AIRFIELD  A  A  E 

38 

-2 

0 

8410050 

Gp02ALTEP'vATE  AIRFIELD  -Ar-E 

38 

-2 

0 

6410051 GF 01 

GF03AIRF1FLD  SY  ‘tOL 

1 

0 

0 

8410052 

GFC4A IRFIELD  EXISTENCE  SEC  CLASS 

3 

0 

0 

8410050 

GF0  5V AGUE  T  1C  VAR1ATI0- 

4 

0 

0 

8410050 

GF06TDI  APE  A  CODE 

1 

0 

0 

841 0062 

GEO  7  YEAR  f)  F  LATEST  1 1  F  Ur'n  A  T  I  G'v 

-2 

U 

0 

84 10050 

GFOdPONTH  OF  LATEST  I'.FuRnaTIOw 

2 

0 

0 

8410050 

GF0S1CA0  DE  S  1  GLaT  OK* 

4 

0 

0 

8410050 

GF  1  OM A X  DEMON  Ij S A f; E  (AC  TYPE) 

4 

0 

0 

8410050 

GF11A/F  FLEVATIOTm 

5 

0 

0 

8410050 

GFldLOGISTICS  PLA.  \  ^IPjAT  CODE 

2 

0 

0 

841 0050 

GF13A/F  FOLDER  iU  fiLk 

6 

0 

0 

8  4  1  0  O  6  0 

GF  1  4GP£P A  T  OP  USER  «E  MArtKS 

38' 

-1 

61 

6410050 

GF15AIRFIELD  STRIP 

1 

(i 

0 

8410050 

GF16ASS0Ta  VOLU-'E  NOMRER 

3 

0 

0 

84  1  0060 

GFl7ASS0Tk".  PO^LICATIO:-  DATE 

-4 

0 

0 

6410061NFMT 

GF16ASS0T*.  nunhEK  OF  PAGES 

-1 

0 

0 

841  0061 MF«T 

GF19ASS0T**-  GRAPHIC  SEC  CLASS 

3 

0 

0 

841  0061GF04 

G  F  2  0  A  S  S  0  T  \m  RECORD  TYPE 

-1 

0 

0 

8410060 

/GF/FAC1LITY  Gt'-tPAl.  information 

30 

0 

30**  76  95  9LA01 

GF21  ASSC'TN  SEC  CLASS 

3 

0 

0 

641 0061 NFMT 

GF22JET  FAClLITTES 

-1 

0 

0 

8410051NFMT 

GF23CC /PRO V 

4 

0 

0 

6410053GF03 

GF24MC 

-4 

0 

0 

8410053GF23 

GFESInSTallaTIG'.  nU'  HER 

-6 

0 

0 

641 0053GF23 

GF  26 DAT  E  OF  LAST  UPDATE  CnAvGES 

-6 

0 

0 

6410051NFVT 

GC27CATEG0KY  CODE 

5 

0 

0 

84  1  00b3GF  03 

GF26GEO  CODE 

4 

0 

0 

6410051GF09 

GF29FACILTTY  GE  >i  INFO  SEC  CLASS 

3 

0 

0 

8410051 GF04 
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■**>•*" 


/GG/GEuGR  Apnli  CO'iK',1  ■  ATES 

16 

0 

in* 

GGOIGEOGRAPhIC  LATITUDE 

7 

0 

0 

GG02GEOGRAPPIC  LOo  G  1  T  UDE 

6 

0 

0 

GG03GEOGK' Ap-IC  COORDINATE  TYPE 

1 

0 

0 

GG04GEU&kAPhIC  LOCATION  ACCURACY 

1 

0 

0 

GG05GRI0  COORD  1  ^aTES 

20 

0 

0 

GG06GRID  SYSTFK 

20 

0 

0 

GG07GE0GK AFHIC  IDENTIFIED 

2 

0 

0 

GGOBaORLD  DIVISION  CODE 

1 

0 

0 

GG096ASE  REFERENCE  POINT  TEXT 

38- 

•1 

372 

GG1 0 GEO GRAPHIC  C 1  > ( . w •  1  s  SEC  CLASS 

3 

0 

0 

/GA/ATM  SOURCE  OF  C  ('06  D  I  K  A  T  E  S 

30 

0 

1  2*  * 

G  A  0 1  A  T  m  n  A  C 

4 

0 

0 

GA02AT9  INST  ALL  AT  1  ui.  UU-’.SER 

-6 

0 

0 

G  A  0  3  A  T  9  SERIES 

-3 

0 

0 

G  A  0  4  A  T  9  PRODUCER 

1 

0 

0 

G  A  0  5  A  T  9.  SnEET  DUMPER 

4 

0 

0 

GA06ATM  SUFFIX 

1 

0 

0 

G  A  0  7  A  T  9  EDITION  f  •  u  t**.  »•  E  A 

2 

0 

0 

G  A  0  8  A  T  9  EDITION  YEAR 

-2 

0 

0 

GA09AT9  EDITION  n.CnTH 

-2 

0 

0 

G  A  1  0  A  T  9  ChART  CL  ASS/MADOL  I  NG 

3 

0 

0 

GA11ATM  C  u  A  R  T  EXISTENCE  CLASS 

3 

0 

0 

/GN/Nf’N'-AT  9  SOURCE  uF  CuO°DINA  1  ES 

24 

0 

9  *  * 

G>  N  0  1  N  D  Im  -  A  T  P  PRODUCER 

2 

0 

0 

GD02D0I.-ATP  SCALE 

-4  . 

0 

0 

GD03D(?n-ATX  SFkIES 

5 

0 

0 

G :m 0 4 Im On -  A  T  x,  S^tFT  Nr  R  / 0  T  n E k  PROD 

12 

0 

0 

GN05DPN-ATP  EDIT  Ion  i.i^i-.ER 

2 

u 

0 

G  D  0  6  D  0  N  -  A  T  9  EDITION  Y  t  A  R 

-2 

0 

0 

G  N  0  7  N  U  N  -  A  T  9  EDITION  M  f  <v  T  *i 

-2 

0 

0 

G  N1 0  8  w  n  9  -  a  T  9  Chart  exist  Class 

3 

0 

0 

/Gk/REFEREI-CES  ,  GhAPmIC 

33 

0 

3*  * 

GRO) GRAPH] l  REFERENCE  TEXT 

3b- 

1 

372 

GR02REFFRENCES,  GRAPHIC  SEC  CLASS 

3 

0 

0 

/GL/LOCAT  ION  x.  la  -O'  ARKS 

33 

0 

3  *  * 

GLOlLOCATlur  K  L  A  '>D  *-  «  *  K  s 

38- 

1 

372 

GL  0  2Ll)C  A  T  I  0Ij  a  L  A"Df-  ARKS  SEC  CLASS 

3 

0 

0 

/gt/tfwraik  *,  r> r a i r  age 

33 

0 

3  *  * 

GT 01  TERRAIN  &  DRAIN/ GE  TEXT 

38- 

1 

6  2  U 

GT02TERRAID  &  D  fc'  A  I .«  a  G  E  SEC  CLASS 

3 

0 

0 

/GC/COMROLLILG  aGE1  CY/aGEnCIES 

33 

0 

3  *  * 

GCOICOnTROL  AGENCY (l£b)  T  t  x  T 

36- 

1 

372 

GC02COOTPDL  AGENCY ( I ES )  SEC  CLASS 

3 

0 

0 

/GS/SIGoIFlCA- Ct 

33 

0 

3*  * 

GSO  1  SIGk'IF  ICAl.Cc  TEXT 

3ft- 

11116 

GS02SIGU1FIC AnCE  T£rT  SFC  CLASS 

3 

0 

0 

621091ULA02 
b«  11  452 

eon  452 

(•'ill  452 
gull  453GG03 
641 1 451 MFM1 
8  4  1  1  451 nFwT 
84  1  1  453GF  23 
6411 450 
8411460 
841  1451GFU4 
76  9 5 1  1 L A 0 3 
8410052 
8410050 
8410050 
841 0050 
6410050 
8410060 
6410050 
84  1  0051 GF07 
84  1  0 05  IGF  08 
84  1  0051 GA  1  0 
6410052 
70101  8  L  A  0  4 

6410652 
8410650 
6410650 
6410650 
8410650 
641^650 
8410650 
6410651GA10 
79  92  2LA05 
64  9760 
64  9761GF04 
79  92  2LA06 
64  9760 
64  9761GF04 
7V  92  2  L  A  0  7 
64  9760 
64  9761GF04 
79  92  2  L  A  o  6 
84  9760 
84  9761GF04 
79  92  2LA09 
84  ° 7  6  0 
64  97MGF04 
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3. 4. 5. 9  Edit  Table  Interfaces 

As  outlined  previously.  Column  24  of  the  Label  Tables  contains  an  edit 
program  control  number  that  determines  —  for  each  data  element  whether 
Format  and  Logical  checks  have  to  be  performed  by  the  on-line  processing 
programs,  and  which  tables  have  to  be  used  (Columns  1,  2  for  'Own'  tables; 
Columns  25,  26  for  'Other'  or  referred  tables).  In  a  similar  way  the  control 
numbers  could  also  be  engaged  for  the  proper  retrieval  of  on-screen  generated 
edit  tables  from  RDOS ,  and  their  subsequent  systems  loading  to  INFOS.  By 
using  the  load  file  INLABEL,  a  'wholesale'  loading  capability  for  all  edit 
tables  could  thus  be  achieved.  The  available  information  would  also  permit 
checks  for  completeness,  and  a  procedure  to  indicate  missing  edit  tables. 

This  capability  has  been  implemented  with  the  systems  program  EPRT. 
Besides  loading  the  edit  tables  to  INFOS,  an  output  file  ETLIST  is  created 
that  spells  out  for  each  data  element  (required  to  have  a  format  or  logical 
table)  whether  and  under  what  table  name  the  loading  has  occurred,  or  which 
table  is  missing.  This  provides  a  most  convenient  check  list  for  ADA's 
system  personnel.  It  greatly  facilitates  maintenance  of  the  system,  even 
when  substantive  changes  have  occurred  that  effect  all  types  of  tables: 

Label,  Format,  and  Logical. 

3.4.5.10  Check  List  for  System  Table  Loading 

A  small  part  of  the  edit  table  check  list  ETLIST  is  presented  on  the 
following  page.  Note  that  for  any  odd  control  number  a  table  with  different 
name  than  the  Data  Element  I.D.  is  listed.  The  control  number  rules,  again, 
can  be  stated  as  follows: 

0  -  Use  'Own'  Format  table 

1  -  Use  'Different'  Format  table* 

2  -  Use  'Own'  Format  and  Logical  tables 

3  -  Use  'Own'  Format,  'Different'  Logical  table* 

5  -  Use  'Different'  Format  and  Logical  tables* 

*  -  'Different'  table  for  'odd'  control  numbers  (entries  in  columns  25, 

26  required) . 
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Data  Element 


Format 

.  Tables 

Logical 

Tables 

Requiring 

Edit  1 

L 

L 

I  .D. 

NO 

GF03 

2 

GF  03 

2 

GF  0  3 

1 

GF  0  4 

0 

GF  0  4 

2 

GF  0  5 

0 

GF  0  5 

3 

GF  Ob 

2 

GF  06 

2 

GF  06 

4 

GF  0  7 

0 

GF  0  7 

5 

GF  Ob 

0 

GF  0  6 

6 

GF  0  9 

0 

GF  0  9 

7 

GF  1  0 

0 

GF  1  0 

8 

GF  1  1 

0 

GF  1  1 

9 

GF  1  2 

u 

GF  1  2 

10 

GF  1  3 

0 

GF  1  3 

1 1 

GF  1  5 

0 

GF  1  5 

1  2 

GF  1  b 

0 

GF)  6 

1  3 

^F  "IT 

1 

GF  1  7 

1  4 

NF*"T 

1 

GF  1  8 

15 

G  F  0  4 

A 

GF  19 

16 

GF  20 

0 

GF  2  0 

1  7 

\F<"T 

1 

GF  2  1 

18 

r.F  vT 

1 

GF  22 

19 

GF  2  3 

3 

GF  03 

3 

GF  2  3 

20 

GF  2 4 

3 

GF  2  3 

3 

GF  2  4 

21 

GF  25 

3 

GF  2  3 

3. 

GF25 

2  2 

K  F  T 

1 

GF  2  6 

23 

GF  2  7 

3 

GF  0  3 

3 

GF  2  7 

24 

GF  0  9 

1 

GF  2 8 

25 

GF  0  4 

1 

GF  2  9 

26 

GGO  1 

? 

GGO  1 

2 

GGO  1 

27 

GG02 

2 

GGO  2 

2 

GG  0  2 

28 

GGO  3 

2 

GGO  3 

2 

GGO  3 

29 

GGO  4 

3 

GG03 

3 

GG  0  4 

30 

NFmT 

1 

GG  0  5 

31 

NF*T 

1 

GGO  b 

32 

GGO  7 

3  MISSING 

GF  2  3 

3 

GG07 

33 

GGO  ft 

0 

GG  0  8 

34 

GF0  4 

1 

GG  1  0 

35 

GAO  1 

2 

GA01 

2 

GAO  1 

3b 

G  A  0  2 

0 

G  A  0  2 

37 

G  A  0  3 

0 

G  A  0  3 

38 

GAG  4 

0 

G  A  0  4 

39 

G  A  0  5 

0 

G  A  0  5 

40 

G  A  0  b 

0 

GA06 

41 

GA07 

0 

G  A  0  7 

42 

GF  0  7 

1 

G  A  0  8 

43 

GF  Ort 

1 

G  A  0  9 

44 

GA  1  0 

1 

G  A  1  0 

45 

44 


3.4.4  Edit  Tables 


J. 


The  entered  (and  frequently  updated)  data  base  information  of  the  Air 
Facilities  Subsystem  will  be  used  by  ADA  and  various  other  Government 
agencies  for  decisionmaking  or  further  data  processing.  It  is  essential, 
therefore,  to  insure  format  correct  entries  that  avoid  costly,  time  con¬ 
suming  (and  embarrassing)  malfunctions  at  the  respective  computer  sites. 
Format  and  logical  checks  of  new  or  updated  data  are  an  important  pre¬ 
requisite  for  making  all  following  programs  and  software  packages  work. 


3. 4. 4.1  Implementation  Alternatives 


There  are  several  ways  for  implementing  format  and  logical  checks  in 
order  to  test  input  data  for  correctness.  Most  frequently,  this  task  is 
accomplished  by  Special  Programs  that  test  and  check  the  user-specified 
conditions  for  various  data  base  elements.  The  software  solution  to  the 
problem,  however,  has  serious  drawbacks.  Special  programming  efforts  are 
time  consuming  and  require  ever  increasing  resources  of  a  system  that  is 
bound  to  grow  in  both  size  and  complexity.  An  'old'  implementation  that 
works  tends  to  prevent  later  improvements  from  being  incorporated.  Changes 
are  costly  in  terms  of  programming  efforts  and  system  outages.  Unless 
everything  is  absolutely  right  from  the  start  (and  stays  that  way  for  years 
to  come)  the  user  may  find  himself  'boxed  in,'  or  he  tends  to  lose  control 
over  his  system  in  spite  of  all  that  good  'modularity'  and  'flexibility' 
of  the  employed  software. 


By  using  a  Boolean  Interpreter  -- an  interpretative  program  that  would 
take  a  data  string  of  meaningful  logical  statements  and  act  upon  accordingly - 
one  could  retain  a  large  degree  of  freedom  for  the  user.  The  interpreter, 
once  implemented,  would  not  require  any  subsequent  program  changes.  The 
user  can  specify  (or  change  his  mind  later  on)  as  often  and  in  whatever 
detail  he  wishes  by  just  forming  another  data  string.  However,  it  must  be 
realized  that  the  formulation  of  interdependencies  in  correct  Boolean  terms 
is  a  cumbersome  process,  mastered  and  properly  understood  only  by  a  few  who. 
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in  turn,  tend  to  become  the  human  ‘bottlenecks'  of  the  system.  A  comprehen¬ 
sive,  free-form  Boolean  Interpreter,  furthermore,  is  not  readily  available. 
Its  development  would  have  required  considerable  effort,  plus  substantial 
system  resources  for  software  implementation. 

To  circumvent  the  outlined  difficulties,  Synectics  has  devised  a  Table 
Driven  Solution  to  the  problem.  It  is  an  interpretive  program  for  the 
evaluation  of  logical  tables.  Like  the  Boolean  Interpreter,  the  computer 
software  need  not  be  changed  or  extended  ever,  yet  it  is  capable  of  handling 
edit  tables  of  any  complexity  or  size  to  accommodate  today's  and  tomorrow's 
needs.  The  table  structure  takes  advantage  of  positional  information  (as 
well  as  the  data  itself);  there  is  no  need  for  parsing  algorithms,  or  for  the 
use  and  the  processing  of  brackets.  The  structured  layout  facilitates  a 
well-defined,  orderly  approach  that  can  readily  be  learned  and  mastered  by 
noncomputer  personnel.  In  fact,  it  has  been  shown  that,  after  a  short 
familiarization  period,  one  can  input  and  on-line  test  the  implemented 
tables  almost  as  fast  as  one  could  write  them  down  in  regular  English 
phrases.  The  ease  of  controlling  all  important  logical  functions  in  this 
manner  is  the  best  guarantee  for  a  responsive  system  that  is  truly  mastered 
and  'owned'  by  the  user, 

3. 4. 4. 2  Format  Table  Rules 

The  rules  for  setting  up  format  tables  are  simple.  There  are  three 
types  of  "Data  Fields"  only,  linked  together  by  simplified  "Logical  Connec¬ 
tors”  (LC) .  The  latter  represent  AND’s  and  OR's.  Brackets  are  implied  only, 
there  are  no  critical  rules  for  matching  them  up  correctly. 


T  G 

N  S 

|l  234  5  678  90 

LC 

L 

_ 

P 

_ 

□ 

X 

□ 

1 

XI 

Data  Field 


The  data  specifiers  T,  G,  N,  S  are  used  as  follows: 


4f 


T — Type  of  Data  Field: 


No  Entry — Regular  OR's 
R  — ASCII  Range 

N  — Numeric  Range 

-  The  minus  sign  in  Column  T  causes  all  elements  in  the  Data  Field 
to  be  interpreted  as  logical  NOT's 

G — Grouping  of  Characters: 

Specifies  the  number  of  characters  per  group,  taken  at  a  time  for 
eva luation 

N — N  Times: 

Indicates  the  number  of  times  a  group  of  G  characters  of  the  input 
data  is  compared  with  the  entries  of  the  Data  Field 

S — Start  Position: 

Character  start  position  of  input  data 

The  logical  connectors,  as  the  name  implies,  connect  one  data  field  to 
the  next  by  simple  AND  or  OR  symbols.  By  using  a  series  of  different  symbols, 
low,  medium  and  high  level  OR's  and  AND’s  may  be  specified.  This  allows  the 
construction  of  complex  logical  expressions  without  any  need  for  complicated 
rules  concerning  the  opening  and  closing  of  brackets. 

0  -  OR  Low  Level 
A  -  AND 

*  -  OR 
&  -  AND 

X  -  OR  -  -  LAST 

E  -  AND  High  Level  NE  LAST  (Negated) 

The  last  line  of  the  table  uses  a  'connector',  of  ' — '  to  specify  the 
end  of  the  table,  or  a  'NE. '  The  latter  indicates  a  'NEgated  Output;'  i.e. 
switching  from  'FAIL'  to  'PASS'  (and  vice  versa) .  Although  this  feature  is 
not  frequently  used  in  practice,  it  comes  in  handy  in  those  applications 
where  it  is  easier  to  specify  in  a  positive  manner  (rather  than  in  negative 
forms)  what  criteria  an  input  should  not  have.  By  negating  the  output  the 
correct  interpretation  is  then  achieved. 
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3 . 4 . 4 . 3  Samples  of  Format  Tables 


The  mentioned  rules  are  almost  easier  to  be  used  than  explained  as  the 
following  samples  indicate.  The  first  three  format  checks  show  both 
stated  requirements  and  table  implementations,  for  the  three  data  base 
elements  GF03,  GF04,  and  GF05« 

L  The  next  page  illustrates  the  establishment  of  specific  character 

categories,  based  on  the  computer- internal  representation  of  the  ASCII 
characters . 

The  third  page  outlines  the  format  requirements  for  AR07,  "Runway 
Aircraft  Capacity,"  and  a  possible  table  implementation  of  that  requirement. 
The  interesting  feature  of  the  presented  solution  is  that  the  allowable 
codes  are  not  just  listed  "as  is'  (with  just  interconnecting  OR’s),  but 
broken  up  in  AND' s  and  OR’s  (low  and  medium)  to  achieve  a  shorter  table  and 
a  faster  processing  sequence. 


GF03 

Airfield  Symbol 


1  Char.  Alpha.  Limited  to  A,  B,  C,  D, 
E,  G,  H,  X. 


T  G  N  s  1  234  5,676  9  0 | LC 

i  ia|b|c|d|egh|x| 


GF04  3  Char.  Alpha.  First  Char  =  U,  S  or  C 

Airfield  Existence  Second/Third  Char  =  NF,  EA,  EN,  EH,  EB, 

Security  Class  EG,  EE,  EC,  EJ,  FP,  WI  or  Blanks. 


TGNSll  234  5  678  9  0  I  LC 


1 

1 

U  |  S 

d 

A 

2 

2 

N  F 

E  A  E  N  E  H 

0 

2 

E  B 

E  G 

E  E  E  C  E  J 

0 

2 

F  P 

W  I 

— 

AND  ( 

OR 

OR 

11  Exit 

23  23  23 


Boolean  Picture  for  GF.04:  )  ] A  (  |  |  O  [  |  O  |  | 


'  GF05 
Magnetic 
Va  ri a  ti  on 


4  Char.  Alpha-Numeric.  First  3  Char,  must 
be  numeric  in  the  range  of  000-179.  Char 
4  must  be  E  or  W.  If  Char  1-3  =  000 
Char  4  must  be  E. 


TGNS  1  234  5,678  90  LC 

N  3  _ 1  0  0  l[  1  7  9  1  A _  Range 

1  4  E  W  *  Exit  if  True 


N  3 

1 

0  0  1 

1  7  9 

A 

1 

4 

E  W 

★ 

3 

1 

0  0  0 

A 

1 

4 

E 

— 

AND 
]  OR  [ 
AND 


123  _ <•  "|  I"  12  3  _ *. 

Boolean  Picture  for  GF05:  (  | A  j  j  lol  f  )  A  |  } 


ASCII  CHARACTER  CODES 


SPECIAL  FORMAT  CHECKS 


7-kll 

Octal  CKaractsr 


ALPHA  CHARACTERS  ONLY 


32 
3) 
3* 

35 

36 

37 
3B 

33 

40 

41 

42 
*3 

44 

45 
44 

47 

48 

43 

50 

51 

52 

53 

54 

55 
55 

57 

58 

53 


040 

041 

042 

043 

044 

045 

044 

047 

050 

051 

052 

053 

054 

055 

054 

057 

060 

041 

062 

06J 

044 

045 

046 

047 

070 

071 

072 

073 


DO 

i 


T  G 

1  2  3  4  5 

6  7  6  9  -gJ 

LC 

dzi  R  1 

a 

z 

- : 

DATA  BASE  CHARACTER  SET 


T  G 

|1  234  5,676  90 

LC 

blank,  $,  = 

Range  '  -  9 

Range  A  -  Z 

1 

R  1 

A 

$  = 

★ 

1 

9 

★ 

R  1 

A 

Z 

— 

NO  FORMAT  CHECK  OF  FIELD 


40 

074 

< 

61 

075 

L£H 

42 

076 

> 

63 

077 

? 

44 

1 00 

8 

65 

101 

A 

44 

102 

B 

67 

103 

C 

48 

104 

0 

63 

105 

K 

70 

io4 

r 

71 

107 

6 

72 

110 

M 

73 

ill 

1 

74 

112 

.J 

75 

113 

ft 

76 

114 

l 

77 

115 

ft 

7« 

116 

■ 

73 

117 

0 

BO 

120 

F 

B! 

121 

Q 

ft? 

122 

ft 

«3 

123 

s 

84 

124 

T 

85 

125 

U 

84 

126 

f 

B7 

127 

V 

88 

130 

I 

83 

1J1 

T 

JO 

132 

7 

T  G  | 

11  2  3-4  5 

6  7  8  9  0 

LC 

|  NOT  in  Range 

L- R  i 

□ 

_ 1 

Z 

— 

▲ 

Every  manually  inserted  character  is  'wrong* 
as  input.  (Effective  prevention  of  manual  inputs) 


OR 

OR 


V>  -  Z 
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AR07 


I 

1 


Runway  Aircraft 
Capacity 


4  Alpha-Numeric.  Allowable  codes 
are  : 


Aircraft 

HelicooterF 

AT 

C124 

F1B1 

06 

~Afil 

A4 

C130 

FI  02 

U7 

AH56 

A5 

C131 

F104 

US 

CK21 

A6 

C135 

F105 

U10 

CK34 

A7 

R1 35 

F106 

U17 

CK37 

A37 

V137 

Fill 

UVT8 

CH47 

£26 

C140 

HU16 

U21 

CH54 

B52 

C141 

01 

HH43 

B57 

707 

02 

0H6 

B66 

727 

on 

0H13 

C2 

747 

OV10 

OH23 

C5 

DCS 

F2 

OR58 

C7 

DC10 

P3 

UH1 

C9 

ien 

T28 

UB19 

C45 

E2 

T33 

C46 

E3 

737 

C47 

E4 

T3S 

C54 

E4 

T39 

C97 

F5 

T41 

C117 

F14 

T42 

C118 

F15 

T43 

C119 

F84 

U1 

C121 

FB6 

U3 

Cl  23 

F100 

U4 

Requirements 


Example : 

The  first  three  lines  of  the 
table  cperify  the  allowable 
codes : 


A  And 

1  or  4  or  5  Or 
6  or  7  or  37  * 


A1 

A4 

A5 

A6 

A7 

A37 


1 

2  3 

41  5  6  7  8 

9 

-TG 

N  5 

1  2341 5t>7  89  0 

LC 

— 

— 

-  - 

1 

1 

A 

A 

3 

2 

1  41  5 

0 

3 

6  7  37 

• 

1 

1 

B 

A 

3 

2 

26  52  57 

0 

3 

66 

* 

1 

1 

C 

A 

3 

2 

2  5  7 

0 

3 

9  9  5  4i  G 

0 

3 

417  541  97 

0 

3 

1  171  181  1** 

0 

3 

1  21  3  231  29 

0 

3 

131135190 

0 

3 

191 

* 

9 

1 

VI  37K1 35 

* 

4 

707  727 

* 

9 

797  DC8 

* 

41 

PCI  01 01 1 

* 

9 

E  2  E  3 

* 

41 

E  9 

* 

1 

1 

F 

A 

3 

2 

41  5  19 

0 

3 

15  89  86 

0 

3 

100101109 

0 

3 

105106111 

* 

41 

1 

Hill  6 

* 

1 

1 

0 

A 

3 

2 

1  2  VI 

P 

3 

VIOHb  H13 

0 

3 

H23H58 

* 

1 

1 

T 

A 

3 

2 

28  33  37 

0 

3 

38  39  91 

0 

3 

4<2  93 

« 

1 

1 

U 

A 

3 

2 

1  3  9 

0 

3 

6  7b 

0 

3 

10  17  HI 

0 

3 

HI 9V1 821 

• 

41 

J 

A  H 1  AH56 

* 

1 

1 

C 

A 

3 

2 

H21 H39H37 

0 

3 

H97H59 

« 

41 

1 

HH9  3' 

• 

1 

] 

0 

A 

3 

2 

H6  H13H23 

0 

3 

H58 

- 

51 


*  / 


3.4.4 .4  On-Line  Table  Verifications 

Synectics  table-driven  solution  to  the  editing  problem  does  not  require 
program  developments  or  program  alterations  to  accommodate  changing  require¬ 
ments.  It  permits  the  ready  system  loading,  testing,  and  documentation  of 
changed  or  new  edit  tables  in  an  interactive  environment  with  immediate 
computer  feedback  for  testing,  verifying,  and  fully  concentrating  on  the 
desired  editing  function. 

This  capability  has  been  achieved  by  implementing  an  or.-line  test  and 
evaluation  package  that  serves  as  a  comprehensive  tool  for  edit  table  design 
and  their  automatic  loading  to  the  system.  This  package  allows  the  func¬ 
tional  verification  of  all  edit  tables  as  they  are  entered  into  the  system. 
It  displays  the  actual  processing  and  response  to  various  classes  of  inputs 
by  showing  in  detail  whether,  where,  and  why  a  table  lets  correct  inputs 
pass  while  incorrect  ones  are  rejected. 

The  built-in  features  serve  two  functions:  (1)  that  of  proper  table 

design  with  an  implicit  training  of  those  analysts  who  are  responsible  for 
establishing  and  maintaining  these  system  controls  and  (2)  that  of  verifying 
and  documenting  the  editing  functions. 

The  letter  can  be  accomplished  by  the  on-line  session  itself  through 
simultaneous  hardcopy  output.  The  generated  output  thus  serves  as  a  basis 
for  documentation  and  system  verification. 

The  following  samples  should  provide  a  good  insight  into  the  creation 
and  on-line  testing  of  such  format  tables.  The  original  table  input  can 
be  achieved  on-line  via  the  special  program  "FKEAD."  This  program  produces 
header  lines  and  automatically  sets  appropriate  tabs  for  simplified  input 
operations.  (For  logical  tables  the  program  "LKEAD"  is  used.)  In  addition, 
card  input  programs  are  available  if  off-line  preparations  through  key  punch 
personnel  are  preferred. 
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Daring  the  on-line  test  session  the  table  input  is  subjected  to  a  formal 
check  to  test  the  presence  of  key  elements.  The  input  is  then  converted  and 
made  ready  for  system  loading.  This  is  accomplished  by  eliminating  the 
header ,  the  automatic  inclusion  of  default  values,  and  by  changing  the  LC 
code  to  (computer-internal ly  used)  numbers.  The  analyst  can  select  from  a 
number  of  options: 

T — Test  of  up  to  5  inputs  simultaneously 
L — Large  test  (one  test  input  has  up  to  29  characters) 

S — Select  or  Switch  from  FORMAT  to  LOGICAL  tables 

C — Change  Table  (for  on-line  changes,  line  insertion  or  deletions) 

E — Exit  the  Test  program  or 
NAME  of  next  table  to  be  tested — 

3. 4. 4. 5  Sample  of  On-Line  Test  Session 

In  the  following  example  'AR17'  the  option  for  5  test  inputs  has  been 
chosen.  Detailed  Data  Field  evaluations  for  each  of  these  inputs  are  dis¬ 
played  plus  the  final  outcome  'FAIL'  or  'PASS.' 


AR1 7 

Runway  Overrun 

Alpha.  Same  codes  as  A.R04  with 

Surface  (Low  End) 

the  addition  of  A,  E,  N. 

AR04 


Runway  Surface 
Composi  tion 


Alpha.  Allowable  codes  are  as 


follows : 
COM,  CON, 
GVL,  ICE, 
PEM,  PER. 


ASP,  BIT, 
COP,  COR, 
LAT,  MAC , 
PSP,  SAN, 


BRI,  CLA, 
GRE,  GRS , 
MEM,  MIX, 
SNO  or  U. 


Original  Table  Input 


1 

P 

? 

u  5  t.  7  o 

9 

-1  G 

l\! 

S 

1  P3iibfo7  690 

LC 

3 

I TRR ] 

* 

3 

CL  ACnMCDN 

* 

3 

COFC'lRGRE 

* 

3 

C-RSGVL  ICE 

Ik 

3 

L  atmacm.em 

ik 

3 

MI x PE  MPE  R 

* 

3 

PSPSANSNO 

Tk 

3 

U  A  E 

* 

3 

N 

— 

(Entered  as  input  file)  A 


Converted  Table 


1  - 

3 

) 

1 

ASPBI1BRI 

3 

- 

2- 

3 

1 

1 

CLACOMCON 

3 

- 

3  - 

3 

1 

1 

COPCORGRE 

3 

- 

n  - 

3 

1 

1 

GRSGVl ICE 

3 

- 

5- 

3 

1 

1 

L A  TMACMEM 

3 

- 

6- 

3 

1 

1 

MI  X  PE MPE R 

3 

- 

7- 

3 

1 

1 

PSPSANSNO 

3 

- 

8- 

3 

1 

1 

U  A  E 

3 

9- 

3 

_ 

1 

1 

N 

8 

(Loaded  to  the  system) 


NAME  OF  TABLE  --  AR17 


TG 

N  S 

DATA 

FIELD 

LC 

© 

U 

A 

PSP 

SSS 

3 

ASP 

B  I  I 

BRI 

fk 

F 

F 

F 

F 

F 

3 

CL  A 

C  0M 

CON 

* 

F 

F 

F 

F 

F 

3 

COP 

COR 

GRF 

* 

F 

F 

F 

F 

F 

3 

GRS 

GVL 

ICE 

* 

F 

F 

F 

F 

F 

3 

LAT 

MAC 

MEM 

* 

F 

F 

F 

F 

F 

3 

Ml  X 

PEM 

PER 

* 

F 

F 

F 

F 

F 

3 

PSP 

SAN 

SNO 

* 

6 

F 

F 

T 

F 

3 

U 

A 

© 

★ 

T 

T 

• 

F 

3 

N 

- 

F 

0 

• 

• 

F 

1 

(fail 

PASS 

PASS 

PASS 

FAIL 

The  above  test  gives  an  example  for  detecting  a  simple  error  in  the  table  design. 
Since  the  (acceptable)  input  ’E'  leads  to  a  'FAIL'  situation,  there  must  be  some¬ 
thing  wrong  with  the  edit  table.  A  closer  inspection  reveals  that  the  'E'  has 
been  placed  in  the  middle  of  the  3-character  group  instead  of  the  beginning. 


These  displays  are  also  listed  in  the  session  file  for  later  printouts 
on  demand.  The  printouts  can  be  used  as  detailed  working  papers  for  (off¬ 
line)  inspections,  improvements,  table  changes,  and  the  preparation  of  next 
on-line  sessions  at  the  system  analyst’s  desk.  Such  use  significantly 
alleviates  a  crowded  terminal  schedule,  and  improves  both  speed  and  quality 
of  the  'next  session'  by  allowing  for  a  better  preparation  than  would  other¬ 
wise  be  possible.  All  tables  tested  during  an  on-line  session  will  auto¬ 
matically  be  loaded  to  the  system.  The  analyst  has  no  choice  in  this  matter 
in  order  to  ensure  that  'what  he  sees,  is  what  the  system  gets.'  A  printout 
of  the  last  test  session  (for  a  particular  table)  should  consequently  be 
kept,  serving  as  the  final  load  and  test  evaluation  document.  Only  'play' 
sessions  are  exempt  from  this  rule. 

3 . 4 . 4 . 6  Format  Checks  for  Geographic  Latitude  and  Country  Codes 

The  following  test  printouts  for  GG01,  "Geographic  Latitude"  and  the 
suggested  three  solutions  to  the  "Country  Code"  edit  check  problem  provide 
good  insights  for  the  use,  inner  workings,  and  the  potential  improvements 
of  such  format  tables. 


ELT 

ELEMENT  NAME 

REQUIRED  EDITS 

GG01 

Geographic  Latitude 

Alpha-Numeric.  First  and  Second 
characters  must  be  numeric  and 
less  than  91,  Third  and  Fourth 
must  be  numeric  and  less  than  60, 
Fifth  and  Sixth  characters  must  be 
numeric  and  less  than  60.  Last 
character  must  be  ' N 1  or  'S'. 

This  Format  Check  Table,  for  Geographic  Latitude  entries,  is  an  example  for  the 
use  of  Logical  NOT 1 s  (-)  and  Numeric  ranges  (N) .  The  first  two  rows 
of  the  table  stipulate  that  the  first  6  characters,  taken  one  at  a  time  (G=l) , 
shall  not  be  'blank'  or  '.'  .  The  following  three  lines  give  the  numeric 
ranges  for  the  two-digit  groups  (N2) ,  starting  at  input  positions  1,  3,  and  5. 


-TG 

S 

1  c1?  4  5  b  7  b  5  0 

LC 

-  \ 

b 

1 

A  -- 

-  1 

b 

1 

m 

A 

t'2 

1 

1 

00  90 

A 

/ 

n2 

1 

3 

00  59 

V 

A  x 

N2 

5 

0  0  5« 

1 

7 

NS 

- 

-TG 

N 

s 

DATA  FIELD 

LC 

-  1 

6 

1 

A 

-  1 

b 

1 

A 

N2 

1 

1 

0  0  =  =  9  0 

A 

N2 

1 

3 

00  ==  59 

A 

5 

00  ==  59 

A 

1 

7 

N  S 

- 

-TG 

K> 

$ 

fa  it  FIELD 

LC 

-  1 

b 

1 

A 

-  1 

*2 

'*2 

b 

J 

I 

1 

1 

3 

Of'  -  = 

till  =  = 

@ 

59 

A 

A 

A 

5 

0  0  =  = 

59 

A 

1 

7 

N  S 

m 

.  Numeric 

Range : 

From  == 

To 

Since  all  Table  rows  are  interconnected 
by  logical  AND's,  the  input  must  be 
true  for  each  table  row  to  PASS. 


Test  Input 

/ 

/ _ _ 

1  2  3  4  5  h  N  ] 


T 

1 

T 

T 

T 

1 

; pass  | 

(sj)?3a5N 

I . 

FAIL 

continued 


y. 


56 


4 

I 


NAME  OF  TABLE 


GG01 


TEST:  --  ]?b2305 


TG 

N  S 

DATA  FIELD 

LC 

1 

6  1 

A 

1 

b  1 

. 

A 

M? 

1  1 

o 

II 

II 

)° 

'O 

A 

,\2 

1  3 

o  o  =  =  (s  <j) 

A 

KB 

5 

00  == 

A 

1 

7 

N  S 

- 

test:  --  i23o5bY 


T  G 

N  S 

DATA  F ] ELD 

LC 

1  2305(0 

1 

b  1 

A 

T 

1 

b  1 

• 

A 

T 

N2 

1  1 

0  0  =  =  9 o 

A 

T 

M? 

1  3 

00  ==  59 

A 

T 

5 

u 0  ==  S9 

A 

T 

1 

7 

N  S  O 

— 

0 

FAIL 

_-jp  DATA  FIELD  LC  The  indicated  row  of  the  table  could 

_  _ _ _  __  have  been  combined  with  the  preceed- 

j  _  j  fc>  1  A  ing  one,  thus  shortening  the  table 

i  _  j  k  i  A  to  the  form  presented  at  left. 

|  N2  j  j  *,0  ==  90  A  By  stipulating  that  the  numeric 

i  ,  .  __  .  range  (T=N)  of  a  2-character  group 

*  '*-)  ^  (  (G=2)  be  tested  two  times'  (N=2)  , 

1  *  7  ^  ^  _ _ starting  at  the  third  position  of 

the  input  string  (S=3),  the  same  format  checks  would  be  accomplished. 


•  V 

*  »  A 

* 

• 

J 

1 

*1  TO 

t  C 

• 

t 

t 

TJ»  /» 

... 

-  - 

• 

J 

1 

||»0  I  IIM>? 

•  c 

•  i 

• 

1 

1 

•  •  5  *  *  •  >  S  •>  ft 

ft  l 

a 

1 

1 

vllOVtSOfc 

•  II 

•  i> 

« 

1 

\ 

i 

.1/ 

ft  TV 

ft 

1 

\ 

-s >  c 

ft  V 

• 

1 

X 

"SI  1 

•  V 

•  « 

ft 

1 

1 

•'A  )  JnS  t  • 

aa 

*C 

ft 

1 

X 

"S  !  •  S  )  ♦» 

Hi- 

HI 

• 

t 

1 

(IS  i  Yl'Sl  • 

B  t. 

• 

1 

1 

..ft  \  B  -SPft, 

r-i 

• 

) 

1 

"S?MS/* 

■  m 

• 

1 

1 

t'S^ilS  »o 

• 

1 

1 

US  S  t  IS  \? 

«*v 

• 

1 

1 

IIS  S  S-IS  »A 

►.  1 

• 

1 

1 

US  IV*  ft*. 

r  • 

• 

1 

t 

US  « 1  US  »s 

f  *• 

CP 

• 

1 

» 

US"*  ftftO 

r  p 

« 

X 

1 

t'M  X  "  S  a  ? 

r  c. 

r  | 

« 

1 

1 

I'SM  '  S  •  ft 

r  j 

i  • 

• 

t 

» 

u  ft  ft  S  '  ft  ft  ft. 

»  » 

t  •» 

• 

X 

1 

yftft  7  "ft  I* 

r  u 

r  j 

• 

1 

1 

U  ft  •  ft  •  •  *  *M- 

r  i 

r  ii 

a 

1 

1 

tfSM  US4*? 

r  v 

l  • 

• 

I 

1 

U**>SuS*»B 

r » 

•-ft 

• 

1 

1 

l»ftb  V5«*** 

u  S  6  7  8 


a  L  a »  *  G  A  n  a  D 
AQtb'.StliAV 

/.  >  3  4  m»«c 
$f  Hk  ?G~  HBI 

,.  piiy,.*,  *  1 

4 

C  b  r  d  r  h  u  r. 
C  1  C  J  r *  c  ML  N 
CUTS':  TCWCV 

c*c  rr  at-ml-o 

D.)1)P*  U  f,»  1 
k  A  E  U  r  S  r  T  f  * 
ff«F]fJFOFR 
F  w  f  S  r-  4  • .  *)  r.  f 
r,H|,]  r%  Ji;lGP 
r.  0 »,  rf  r,  S  G  T  G  V 

6YG7H4HKMM 

HO  1C  JUJMJU 
icjiwjs]  n  v 

!  Y  I  7  J4.IH.Ml 
.1  S*F  *  S*  T  nD 
L  4 1  F l  IlSlT 
L  til  r*4MBSC 
MH  «t  1  *<•1  VN*-0 

I'pvRMk^lHI) 
wvMl“YM7Ni 
NC  ME «vF M6MH 
N  J  Nl  W0I<P^B 
w5NJK7p4PC 
p£  p&mPNPO 
PPPQPllDARE 
PhSPB!^! YS  a 
SbSC5E5FSG 
ft  *«  S  l  ft  **  S  N  S  0 
5PSl$i»**SY 
S7tCTOlHTK 

UTMniMO 

1  ST  ul V 1 *T  7 

Ilft'IA  IIVU Y  VC 
Vf  V )  V-VUVT 
•ft  A  ftlf  «*  1  *  Hf  S 
rt7  rf  Yf'T  S7  4 

us 

c  *> 

Cl  ** 


THREE  SOLUTIONS 

TO  THE  HANDLING  OF  EDIT 
CHECKS  FOR  1  COUNTRY  CODES ' 

(1)  Long,  unsophisticated  table 

(2)  Compact  Format  table 

(3)  Fast  working  table  arrangement 
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(For  greater  detail  see  the  following  pages) 
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F 

F 

F 

F 

F 

(1)  UNSOPHISTICATED  TABLE 
'COUNTRY  CODES' 


For  space  considerations  only 
a  part  of  the  table  (with  test 
pattern  for  five  inputs)  is 
presented  here. 


Data  Field  Evaluations: 

T  -  True  (match  with  in¬ 
put) 

F  -  False  (no  match) 

.  -  Skip  Data  Field 
Evaluation 


1  VS 

vz 

»  F 

. - 

F 

F 

“ 

I  'TE 

YO 

t  F 

f 

F 

l 

re 

l  F 

F  . 

_F_ 

i'sn 

use? 

t  F 

F 

F 

1 

jse3 

US04 

1  F 

F 

F 

1 

USBS 
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t  F 

F 

F 

1 

use? 

uses 

1  F 

F 

F 

1 

use  9 

US  ID 

t  F 

F 

F 

1 

USl  1 

USl  ? 

»  F 

F 

F 

1 

US1  3 

US  1  4 

*  F 

F 

F 

1 
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file. 

*  F 

F 

F 

1 

USl  ? 
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F 

F 
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F 

F 

1 

USB  1 
USB  2 
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F 

T 

F 

F 

1 

1 
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USB? 
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US?? 
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F 

F 

— - 

1 
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u'3e 
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F 

s 
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US  32 
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1 

US23 
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1 
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1 
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1 

US  4  1 
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1 
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1 

DS4  5 
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F 

1 
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i 
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F 

i 
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1  F 

F 

i 
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Ut5t 

F 

F 

fa: 

L  PASS 

PASS 

PASS 

Relatively  few  data 
fields  can  be  skipped 
with  this  table  arrange¬ 
ment,  resulting  in 
longer  processing  times. 

Note  in  particular  the 
considerable  amount  of 
comparisons  required 
for  all  'US'  codes. 
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US23 


USA 


(2)  COMPACT  TABLE 
’COUNTRY  CODES' 
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fail  pass  pass 


r£T  □□ 

This  table  is  much  shorter 
(full  table  reproduct ion) . 
In  addition/  the  number  of 
data  fields  that  must  be 
checked  is  greatly  reduced. 
The  latter  is  accomplished 
by  testing,  in  the  first 
row  of  the  table,  whether 
or  not  the  3rd  and  4th 
character  is  'blank' 

(i.e.  a  character  group 
of  G=2,  taken  N=1  times, 
starting  with  the  character 
‘  position  S=3  of  the  input)  . 

;  This  separates  all  2-aigit 
foreign  country  codes 
usa  from  those  of  the  4-digit 
US  codes.  If  the  first 
data  field  is  F  (indi¬ 
cating  a  possible  'US' 
code)  then  all  data  fields 
containing  'foreign' 
(2-digit)  codes  will  be 
skipped  (.)  by  the  table 
evaluation  in  program. 

pass  FAIL 


The  improved  evaluation  pattern  is  achieved  by  the  chosen  Logical  Connectors 
@  through  (*) .  The  first  data  field  'AND'  one  of  the  following  data  fields 
must  be  'T'  to  satisfy  the  format  check.  Conversely,  if  the  first  data  field 
is  'F'  then  the  subsequent  data  entries  need  not  be  checked.  (Even  if  they 
were  right,  the  format  check  would  not  be  complete).  In  this  situation  the 
program  skips  all  subsequent  data  fields  until  the  higher  level  OR  ®  is 
encountered . 

Furthermore,  the  rather  lengthy  listing  of  56  individual  ’US'  codes  in  solution 
(1)  has  been  reduced  to  three  lines  in  this  table: 

-  The  first  line  checks  whether  the  first  2  characters  are  'US' 


-  The  second  line  tests  whether  the  3rd  and  4th  character  are 
truely  numbers.  This  prevents  an  input  of,  say,  'US3'  instead 
of  the  correct  input  US03 


-  The  third  line  checks  whether  the  2  digit  numerical  code  falls 
within  the  appropriate  range  from  01  to  56 
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(3)  FAST  WORKING  TABLE 
'COUNTRY  CODES' 


This  table  design  goes  one 
step  further  in  that  the  two 
character  combinations  of  the 
foreign  country  codes  have 
been  split  up  to  achieve 
greater  processing  economy. 

For  example,  take  the  first 
three  lines  of  the  second 
Dart  of  the  table: 


AHCH1 1.NOPQ 
K'J'UVXY  Z 


foil 


t 

T 

1 

rots 


The  first  character  'M'  together  (AND)  with  one  of  the  following  characters 
(OR)  of  the  next  two  lines  form  the  acceptable  country  code  combinat ions : 

MA  MB  MC  MH  MI  ML  .  .  .  MZ 

However,  if  the  first  character  of  the  given  input  does  not  match  'M',  then 
the  characters  of  the  following  two  lines  need  not  be  checV.ed.  This  arrange 
merit  of  course,  further  speeds  up  the  evaluation  of  this  format  check  table 
(altnouah  the  table  itself  is  somewhat  longer  than  the  one  in  solution  (2). 

Note  that  all  edit  tables  (1),  (2),  and  (3),  despite  their  different  struc¬ 
tures  and  processing  per formance  always  lead  to  the  same  format  test  results 


3. 4. 4. 7  Logical  Check  Tables 

At  present,  the  following  functions  are  achieved  by  the  edit  tables: 

1.  Format  Checks  of  all  inputs  to  the  data  base  (pass/fail  decisions 
per  data  base  element) 

2.  Logical  Checks  for  a  test  of  specified  correlations  between  selected 
data  base  entries  (pass/fail  decisions  per  logical  record) 

3.  Computed  Inputs  for  the  automatic  insertion  of  information  as 
triggered  (and  in  relation  to)  other  data  base  entries 

4.  Boolean  Searches  for  the  selection  of  individual  records  based  on 
specific  intercorrelations  of  their  information  contents 

5.  Password  Processing,  and  the  correlation  or  limitation  of  password/ 
analyst  functions 

The  format  checks,  discussed  in  the  previous  section,  deal  only  with 
a  specific  data  base  element,  one  at  a  time.  While  a  particular  element 
entry  or  update  might  be  'correct'  in  a  formal  sense  (and  thus  may  not  be 
'detected  as  false'  by  the  appropriate  format  check  table) ,  it  might  not 
make  much  sense  with  regard  to  other,  related  information  for  that  record. 

To  test  those  interrelations  with  other  data  base  elements,  only  minor 
extensions  to  the  format- table  concept  are  needed,  such  as  the  inclusion  of 
an  'Element'  column  (to  name  that  related  data  element)  plus  three  more 
logical  connectors. 


IF 

TH 

SE 


IF 

THEN 

SET 


The  choice  of  IF,  TH,  and  SE  as  addition  to  the  array  of  logical 
connectors  has  been  deliberate.  It  makes  the  design  of  logical  tables  quite 
simple  by  letting  the  procedures  closely  resemble  the  logic  inherent  in  the 
English  language  (if,  then,  set).  It  also  is  a  completely  sufficient  ex¬ 
tension  to  boost  the  available  table  capabilities  from  mere  format  checks 
to  the  most  complex  logical  procedures  imaginable. 

In  this  context  one  should  note  that  the  above  list  of  functions  only 
represents  the  current  use  of  such  tables.  Much  more  is  possible,  from 

problems  such  as  proper  hyphenation  to  complex  language  processing  or 
graphic  design  tasks  based  on  sets  of  correlations  between  given  information 
and  constraints.  In  fact,  it  is  recommended  to  reserve  for  the  table  approach 
all  those  logical  functions  of  the  system  that  the  user  wishes  ultimately 
to  control.  The  resulting  software  (using  such  tables)  is  relatively  uncom¬ 
plicated,  and  also  very  stable  in  time  since  all  that  may  change  are  those 
tables  (which  are  treated  as  data  and  not  as  programs!).  Thus  the  cost  of 
'experimenting'  is  greatly  reduced,  and  the  user  can  truly  attain  maximum 
utility  of  his  system  in  a  convenient,  on-line  environment  that  lets  him 
try,  decide,  and  continue  to  bring  out  the  best. 

* 

3. 4, 4. 8  Sample  of  Logical  Checks 

The  following  four  sample  sheets  concern  the  data  base  element  GF2"/ 
"CATEGORY  CODE."  They  show  the  spearation  between  format  and  logical  checks, 
and  how  the  latter  can  be  formulated,  implemented  and  tested  to  fulfill  the 
requirements  specified  by  the  user. 
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ELT 


ELEMENT  NAME 


REQUIRED  EDI TS 


GF27  Category  Code 


Format  Checks 
for  GF27 


Logical  Checks 
for  GF27 


The  update  information  for  a  specific 
data  element  has  already  passed  a 
pertinent  Format  Table  before  enter¬ 
ing  the  Logical  Check  table.  At 
this  point  the  input  must  be  con¬ 
sidered  'true',  at  least  from  a 
'format'  point  of  view. 

There  are  many  instances,  however, 
where  a  format- correct  input 
could  be  'false'  (or  make  no  sense) 
if  correlated  with  other  information 
in  the  record.  The 'Required  Edits' 
of  the  table  to  the  right  specify 
in  detail  the  valid  interrelations 
between  various  data  base  elements. 

To  implement  and  test  those  condi¬ 
tions,  software  for  the  input,  pro¬ 
cessing,  and  testing  of 
'Logical  Tables'  have  been  written. 
The  following  pages  show  and  discuss 
implementation  and  test  sessions  of 
the  'GF27'  Logical  Table. 


Alpha-Numeric.  Allowable  codes 
are:  80000,  80010,  80020,  80040, 

80050,80060,  80070,  80080,  80090, 
80100,80110,  80120,  80130,  80150, 
or  5  blanks. j  Blanks  are  only 
allowed  when  first  two  characters 
of  GF23  are  ’US’ . 

If  entry  is  80010,  80020  or  80040: 
GD12  must • be  ’ I ' 

If  entry  is  ’80060'  or  '80080': 
AR02  (Primary  Rwy)  must  be  2. 
7070 

AR05  must  be  ' P ' 

If  entry  is  '80070'  or  80090': 

AR02  (Primary  Rwy)  must  be 
4970-7069 
AR05  must  be  'P' 

If  entry  is  '80100': 

AR02  (Primary  Rwy)  must  be 
3970-4969 
AR05  must  be  'P' 


AR02  (Primary  Rwy)  must  be  ^ 
4970 

AR05  must  be  'T'  or  'N' 

If  entry  is  ’ 80110 ' : 

AR02  (Primary  Rwy)  must  be 
2970-3969 
AR05  must  be  'P' 


AR02  (Primary  Rwy)  must  be 
2970-4969 

AR05  must  be  'T'  or  'N' 

If  entry  is  '80120: 

AR02  (Primary  Rwy)  must  be  ■< 
2970 

GD1.2  must  be  'I' 


'  A.  •k  .  ..Z, 


TRANSLATION  OF  EDIT  REQUIREMENTS  INTO  TABULAR  FORM 


ELEMENT 

T 

V 

G 

N  S 

n 

2 

3 

4 

5 

6 

7 

6 

9  0 

iB9 

6>F21 

|5 

1 

<■- 

\wm 

P 

1 

■ 

in 

1 

■ 

! 

1 

03 

U 

E 

■ 

!l 

1 

1 

■ 

■ 

1 

na 

S' 

a 

s 

0]# 

li# 

■H 

tv 

E 

I 

Z  i£ 

o 

y 

■ 

8 

*)I0 

■ 

II 

■1 

Esa 

6  D 1 2. 

i 

i 

1 

■ 

1 

n 

IF 

S' 

■ 

2 

|6 

0 

0 

10 

1012  ie 

TH 

Ape-2 

S' 

m 

1710 

2 

0 

0 

0*IS 

A  . 

AR0y 

1 

m 

P 

t 

IT 

IF 

y 

m 

17 101 

\& 

12 

1010 

na 

AP02 

y 

m 

010 

710 

r 

0 

6  10 

H 

i 

■ 

P 

1 

1 

i 

na 

y 

8 

le-ineie 

TH 

AR-02 

3|0 

20 

1 

0 

6  10 

A 

A  MK 

r 

i 

P 

1 

1 

APei 

K/ 

y 

1 

0 

70 

2 

s 

0 

010 

A 

i 

T 

K/ 

1 

1 

IF 

y 

8 

# 

1 

lie 

TH 

A  2-0  2 

y 

2 

0 

7  0 

3 

0 

6  0 

A 

A  2#  b 

i 

P 

* 

A  P02 

A 

y 

2! 

0 

70 

0] 

0 

A  10 

A 

A  2-0  S' 

i 

T 

N/l 

1 

IF 

y 

8 

0|J  1 

21 

0 

1 

TH 

AP^2 

N' 

y 

1 

J 

0 

T| 

710 

A 

&t>12 

— 

i 

I 

J 

J 

J 

— 

— 

— 

1 

IF 

1st  line  must  be  IF  01  SE 

IF  GF27  is  ’blanJc'  TKen 
GF23  must  be  'US’ 


IF  GF27  is  80010,  80020 
OR  80040  TKen 

GD12  must  be  * I* 


IF  GF27  is  80100  TKen 

AR02  Num.  Range: 

3970-4969  And 
AR05  must  be  'P‘  Or 
AR02  Num.  Range: 

4970-20000  And 
AR05  must  be  'T'  or  'N' 


*In  case  of  unspecified  element  fields  the  program 
substitutes  the  element  name  of  the  first  row. 
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SYSTEM  IMPLEMENTATION  OF  'LGF27 ' 


i 


I 


The  table  design  of  the  pre¬ 
vious  page  may  be  implemented 
on-line  via  the  terminal  using 
the  program  'LHEAD'  (which 
provides  header  lines  and 
sets  the  appropriate  tabs) ; 
or  via  the  card  reader  using 
program  'CDT'. 

The  hand-drawn  lines  facili¬ 
tate  interpretation  of  the 
various  IF  -  THEN  'sentences' 
Note  that  within  each  IF  and 
THEN  group  the  full  range  of 
logical  connectors  can  be 
employed,  from  low  to  high 
level  AND’s  and  OK's.  This 
allows  the  creation  of 
logical  structures  within 
each  IF  or  THEN  sequence, 
providing  ample  capabilities 
for  handling  numerous  complex 
logical  intercorrelations. 


The  basic  rules  for  the  use 
of  logical  tables  are  simple, 
however.  Only  if  the  listed 
element  matches  the  specified 
IF  condition  (t)  must  the 
subsequent  THEN  condition(s) 
also  be  tested  and  fulfilled 
©  in  order  to  'PASS'  the  logical  table.  In  other  words  whenever  the  IF  condi¬ 
tion  is  (?) ,  the  subsequent  TH  entries  need  not  be  tested  at  all.  This  can 
readily  be  seen  by  inspecting  the  test  session  print  out  of  the  following  page. 

0  - 

A  - 

*  - 

LC  -  LOGICAL  CONNECTORS  &  * 


IF  -  IF  X  - 

TH  -  THEN  E  - 


OR 

AND 


Low  Level 


OR 

AND 


OR 

AND 


Hiofi  Level 


1  0  1 

1 

2  3 

9  5  6  7  6 

9 

ELEM 

-T  G 

N  S 

1  239567  690 

LC 

GF  27 

5 

IF 

s 

T  H 

GFB3 

? 

US 

IF 

S 

8001 060020 

0 

5 

8  0  0  A  0 

TH 

GDI  2 

1 

I 

IF 

S 

8006080060 

TH 

61?  0? 

5 

707020000 

A 

ARCS 

1 

P 

IF 

5 

8007060090 

TH 

61?  0  2 

NS 

9970  7069 

A 

6  R  0  5 

5 

P 

IF 

5 

8  0  10  0 

TH 

A  r?  0  2 

NS 

3970  9969 

A 

6  R  0  5 

I 

P 

* 

A  R  0  2 

NS 

997020000 

A 

A  P  0  5 

1 

TN 

IF 

5 

80110 

TH 

A  R  0  2 

N5 

2970  3969 

A 

AROS 

1 

P 

* 

A  R  0  2 

NS 

2970  99b9 

A 

A  R  0  5 

1 

T  N 

IF 

5 

80  120 

TH 

A  R  0  2 

NS 

0  297  0 

A 

GD  1  2 

1 

I 

IF 

5 

60  130 

TH 

GDI  0 

1 

I 

A 

GD  1  2 

) 

I 

IF 

5 

80150 

TH 

GD  1  2 

1 

I 

“  — 

r  "*»•<*• 
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NAME  of  TABLE 


Ltf  2  7 


TEST  INPUTS: 


6  0  0  0  0 


- -  60020  - -  60100 
Up  to  5  test  inpust  may  be  used 


60110 


ARC? 
A  R  0  S 
C-D10 
GDI  2 
GE23 
GF27 

A. 


The  test  program  considers  all  elements 
mentioned  in  the  table.  After  sorting  --  and 
the  elirr.inati on  of  all  duplicate  entries  — 
the  remaining  element  labels  are  displayed 
for  data  input  by  the  test  personnel 

US 

*  * - - - 

'  - - - - A  '**'  input  allocates  the  five  inputs 

to  the  specified  element  (GF27) 


EL  EM 

-T  G 

N  S  DATA  FIELD 

LC 

8  0  0  0  0 

60020 

80100 

60110 

PF  27 

S 

1  F 

# 

• 

s 

5 

T  H 

F 

F 

F 

F 

GF  23 

2 

US 

1  F 

• 

• 

• 

_ 0__ 

s 

6  0  0  10 

8  0  0  2  0 

0 

F 

© 

F 

F 

5 

600^0 

TH 

F 

• 

F 

F 

GDI  2 

1 

1 

IF 

• 

T 

• 

- 

s 

6  0  0  60 

60060 

T  H 

F 

F 

F 

F 

A  R  0  2 

S 

7  07  0 

2  0  0  0  0 

A 

• 

• 

- 

• 

A  R  0  5 

1 

P 

IF 

• 

• 

• 

• 

s 

6  0  0  7  0 

6  0  0  9  0 

T  H 

F 

F 

F 

F 

A  R  0  2 

NS 

4970 

=  =  7  0  6  9 

A 

• 

• 

• 

• 

AR0S 

3 

P 

1  F 

• 

• 

• 

• 

~~ 5” 

60100 

TH 

F 

F 

© 

F 

A  R  0  2 

N5 

397  0 

=  =  4  9  6  9 

A 

• 

T 

• 

A  R  0  5 

1 

P 

* 

- 

• 

F 

• 

A  R  0  2 

N5 

4  97  0 

==  20000 

A 

• 

• 

© 

• 

A  R  0  5 

1 

1  N 

1  F 

_ 

, _ 

_ . _ 

•  _ _ 

S  ~ 

60  110 

T  H 

F 

F 

© 

A  R  0  2 

NS 

297  0 

=  =  3  Q  6  9 

A 

. 

• 

• 

F 

A  R  0  5 

1 

P 

* 

• 

* 

• 

• 

a  R  0  2 

N  5 

297  0 

=  =  4  0  6  9 

A 

0 

• 

• 

T 

A  R  0  5 

1 

T  N 

IF 

0 

• 

T 

*" 

S 

6  0  1  2  0 

TH 

F 

F 

F 

A  R  0  2 

NS 

0 

=  =  2  9  7  0 

A 

• 

• 

• 

GDI  2 

1 

1 

IF 

0 

• 

•  _ 

5 

60)30 

T  H 

F 

F 

F 

GDI  0 

1 

1 

A 

• 

• 

• 

• 

GDI  2 

1 

I 

1  F 

• 

• 

• 

• 

s 

6  0  1  S  0 

1  H 

F 

F 

• 

F 

GDI  2 

1 

1 

“  " 

• 

* 

I F  A  I  Cl 

• 

— 

PASS 

PASS 

PASS 
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3. 4.4.9  Sample  of  Computed  Inputs 

The  next  four  sheets  give  an  example  for  a  computed  input  to  the  data 
base.  The  rules  of  interco.rrelation  with  other  data  are  so  complex,  that 
the  user  wanted  to  eliminate  human  input  altogether  in  order  to  achieve  an 
accurate  categorization  for  NN01,  "Naviqation/Communication  Aids."  The  edit 
requirements  for  this  data  field  depend  upon  the  entries  in  NN02  through 
NN19. 

The  computer  sets  (Logical  Connector  'SE' )  the  data  base  element  NN01 
to  the  information  listed  in  the  Data  Field,  if  the  preceding  IF— sentence 
is  'true'  By  starting  with  the  entries  of  lowest  priority  it  is  ensured 

that  the  last  'setting'  of  NN01  is  indeed  that  of  highest  priority  for  the 
record  in  question.  To  simulate  the  three  groups  A,  B,  C  of  the  edit 
requirements  listed,  variables  named  AAA,  BBB,  and  CCC  have  been  used  in 
the  following  tables.  They  are  'initialized'  to  '0'  at  the  start  of  the 
table  to  ensure  their  proper  functions. 


COMPUTED  INPUTS 


SUBCATEGORY :  NAVI CATION /COMMUNICATION  AIDS 


ELEMENT  NAME 


REQUIRED  EDITS 


NN01  N/C  Aids 


Alpha-Numeric.  Generated 


GROUP 

If  one  or  more 
of  these  elements 
contain  an  ’A1 

This  code 
will  be 
generated 

A 

KN08,  NN09,  NN14 

1 

B 

NN10,  NN11 ,  NN12, 
NN13 ,  NN19 

2 

C 

NN16 ,  NN17 ,  NN18 

3 

If  one  or  AND  one  or 
more  of  the  more  of  the 
elements  in  elements  in 
this  group  this  group  This  code 
contains  an  contains  an  will  be 
'A'  'A4  generated 


If  one  or  more  of  the  elements  in 
all  groups  contain  an  'A'  the 
generated  code  will  be  7. 

If  none  of  the  groups  contain  an 
'A'  the  highest  priority  avail¬ 
ability  code  will  be  generated. 
Descending  priority  is  'E',  'U' 
then  ' N ' . 


NAME  OF  TABLE  --  LNNP1 


AAA 
B  bB 

ccc 

MNP  1 

nnO? 
N  N  0  3 

NNO  A 

k'NO  5 
rjfjOh 
nn0  7 
N  N  0  ti 
N  N  0  9 
N  N )  0 
NN)  1 
n;j  l  2 
nn  i  3 
NM  o 
NN  1  5 
NN  1  b 
NN  1  7 
M  N  1  b 
NN  ]  9 


For  this  test  elements  NN02  through  NN19 
of  the  data  base  are  presumed  to  be  at  the 
the  values  indicated  at  left. 

NN01  must  be  set  —  and  with  it  variables 
AAA,  B3E ,  CCC  —  (Computed  inputs) .  Their 
current  values  are  presumed  to  be  an 
(impossible)  *9’,  i.e.  a  residual  computer 
value  at  these  memory  locations. 


ELEm 

NN  0  1 

AAA 

BBB 

CCC 

-1  G 

1 

1 

1 

1 

N  S 

© 

© 

© 

NNO  2 

1 

n 

N  N  0  3 

1 

N 

N  N  0  U 

1 

N 

NN  0  5 

} 

N 

NNOfe 

1 

N 

N  N  0  7 

1 

N 

nno  a 

1 

N 

NNO  9 

1 

N 

NN  1  0 

) 

N 

NN]  1 

1 

N 

N  N  )  2 

N 

NN  )  3 

1 

N 

NN)  U 

1 

N 

NN)  5 

1 

N 

nn  )  a 

) 

N 

NN  )  7 

1 

N 

nn]  a 

] 

N 

NN)  9 

1 

N 

Initialization  of 
AAA,  BBB ,  CCC 
to  1 0 ' 


NNOfl 

1 

U 

0 

ELEM 

-TG 

N  S 

DATA 

FIELD 

LC 

NN09 

1 

U 

n 

MM  0 

1 

u 

0 

MM  1 

1 

u 

0 

NN  1  ? 

1 

u 

0 

fvNl  3 

1 

u 

0 

NN  1  <4 

1 

ll 

0 

MM5 

1 

u 

0 

NN)  b 

1 

u 

0 

NM]  7 

1 

u 

0 

NN1  6 

1 

l) 

0 

NN]  9 

1 

u 

SE 

) 

(u) 

IF 

NNO? 

1 

E 

0 

NN03 

1 

E 

0 

N  N  0  9 

1 

E 

0 

nNOS 

1 

E 

0 

NNO  b 

1 

E 

0 

NNC'7 

1 

E 

0 

nn  n  6 

1 

E 

0 

NN09 

1 

E 

0 

NN  1  0 

1 

t 

0 

NN1  ] 

1 

E 

0 

NM  ? 

1 

E 

0 

NN1  3 

1 

E 

0 

NM  9 

) 

E 

0 

NN]  5 

1 

E 

0 

NN1  b 

1 

E 

0 

NN  1  7 

1 

E 

0 

NN1  8 

1 

E 

0 

NN  1  9 

1 

E 

SE 

ELEM 

-TG 

N  S 

DATA 

F  I  ELD 

LC 

_ _ 

- - 

— 

— 

—  — 

1 

© 

IF 

N'N  0  h 

1 

A 

0 

NNO? 

1 

A 

0 

NNl  9 

1 

A 

SE 

A  &  A 

1 

SE 

1 

© 

IF 

© 


4 


© 

F 

© 


NN01  —  U 
(set  to  ’U') 


0  NN01  — 


E 


1 

1 
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3.4.4.10  Boolean  Retrieval 

The  logical  tables  may  also  be  used  to  perform  Boolean  Searches  over 
parts  of  the  data  base,  or  the  full  data  base  (worldwide  search).  This  is 
accomplished  by  listing  the  desired  conditions  (or  value  ranges)  of  selected 
data  base  elements  in  an  IF  sentence,  followed  by  a  SET  command  for  an  output 
variable.  In  this  way  the  record  identification  (airfield)  can  be  listed 
in  a  special  retrieval  file  for  output  processing  (report  generation  or  type) 
whenever  the  output  variable  has  been  set. 

For  a  simple  example  of  a  Boolean  Search  table,  see  the  following  page. 


SAIR  REQUESTS: 


BOOLEAN  RETRIEVAL 


From  full  AAFIF  file  print  all  airfields  with  hard 
surface  runway  of  5000  feet  or  greater  in  the 
following  countries: 

1 .  South  Afri ca  (SF) 

2.  Rhodesia  (RH) 

3.  Uganda  (UG) 


The  above  boolean  search  request  involves  the 
data  base  elements: 

GF2 3  -  COUNTRY  CODES:  SF  RH  UG 

AR02  -  RUNWAY  LENGTH:  5000  to  20000  (Max) 

AR04  -  SURFACE  COMPOSITION:  ASP  BIT  CON  (Hard) 

The  following  simple  table  thus  expresses  all  con¬ 
ditions  for  the  above  boolean  search  request. 


3.4.4.11  Edit  Tables  Loaded  to  the  System 

The  following  is  the  beginning  of  the  list  of  edit  tables  as  currently 
loaded  to  the  Air  Facilities  System.  The  printed  list  EREPRT  has  been 
created  by  program  EPRT  while' converting  the  edit  tables,  filed  in  RDOS,  into 
the  final  form  and  loading  them  to  INFOS.  The  printout  also  contains  error 
messages  if  formal  errors  have  been  detected.  The  presented  pages  represent 
only  a  small  sample. 

The  table  design  has  been  based  on  the  specified  user  requirements  as 
outlined  in  the  document  "AAFIF  EDIT  REQUIREMENTS,  GENERAL  INFORMATION", 

12  December  1977. 


FORMAT  TABLES 


LOGICAL  TABLES 


1  RDOS  FORMAT  TABLE  FGF03 
1  23  <i  5  b  7  8  9 

-TG  N  S  l?3B5t7t90  LC 


GF03 


A0CDEGHX 


RDOS  LOGICAL  TARLE  LGF03 


A/ 


10  1 

1 

2 

3 

a  5  fe  7  8 

9 

ELEM 

-TG 

N 

S 

1  234567  8  90 

LC 

GF03 

1 

IF 

GF03 

1 

A3C 

TH 

A*  ft*  U  1 

-01 

UN 

A 

G  F  1  0 

-Cl 

A1 . 

A 

i 

C-R27 

-05 

8013080150 

A 

$ 

GO  02 

-01 

D 

A 

* 

GO  03 

-01 

3  A  u 

IF 

A 

GFC3 

i 

r> 

TH 

Grift 

-C  i 

f. 

IF 

£ 

G“C  3 

E 

T-i 

OCOl 

Bi 

A 

Gc  1  0 

-O’. 

IF 

s-, 

v  / 

3-03 

G 

Tl, 

V 

OCOl 

1 

V 

A 

i- 

:-"ir 

* 

\* 

A 

3  0  1  •  • 

* 

I 

i> 

3  011 

I 

A 

3012 

• 

I 

6 

30  13 

• 

I 

A 

3C?7 

5 

8  0130 

A 

■v  U  l)  1 

4 

L 

WIPMMWI 


t  V  :■ 


'  A  02 

« 

V 

A 

>(?/. 

i 

'i 

A 

a  e  o  5 

i 

N 

A 

A  a  06 

1 

K 

TF 

GFO? 

i 

H 

TH 

GF  27 

5 

80150 

IF 

GF03 

1 

X 

th 

GF27 

5 

80130 

A 

GF1S 

1 

D 

IF 

GF27 

5 

TH 

GF23 

2 

1 

US 

IF 

GF  2  7 

3 

3 

010020090 

TH 

GD 1  2 

1 

1 

I 

IF 

GF  27 

3 

3 

060080 

TH 

Aft02 

N5 

1 

0707099999 

A 

A?02 

-01 

5 

1 

• 

IF 

GF27 

3 

1 

070090 

TH 

Aft02 

NS 

1 

0997007069 

A 

6  PC  2 

-01 

5 

1 

• 

A 

A  ft  0  5 

1 

1 

1 

P 

IF 

GF  27 

3 

3 

100 

TH 

A  P  0  2 

MS 

1 

0397009969 

A 

A  *02 

-01 

5 

1 

. 

A 

AP05 

1 

1 

P 

* 

A  ft  0  2 

n5 

0997099999 

A 

AP02 

-01 

5 

1 

. 

A 

A  ft  0  5 

1 

1 

1 

TN 

IF 

GF27 

3 

3 

110 

th 

A  ft  0  2 

N5 

1 

0297003969 

A 

a»02 

-01 

5 

1 

• 

a' 

A  ft  (.  5 

1 

1 

P 

* 

A  ft  0  2 

N5 

0297009969 

A 

AP02 

-01 

5 

1 

• 

A 

A  ft  0  5 

1 

1 

TN 

IF 

GF  2  7  ' 

3 

3 

120 

TH 

a  ft  0  2 

im5 

1 

0000002969 

A 

A  ft  0  2 

-01 

5 

1 

• 

A 

GP  1  2 

1 

1 

1 

1 

IF 

GF  2  7 

3 

3 

1  30 

Th 

GDI  0 

1 

1 

1 

A 

GDI? 

1 

1 

1 

A 

GFo3 

1 

1 

G 

IF 

GF  27 

3 

3 

150 

TH 

GDI? 

1 

1 

I 

A 

GF  0  3 

1 

1 

h 

—  — 
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c  -'DOS  F  ! i K  'AT  1  A ri L r  f> t-  ,i  U 
2?  A  S  o  7  6  9 

TG  'V  S  1 239  5*  7  *>90  LC 

110  A 

2  2  * 

1  1  CS  A 

2  2  .FEAr.tr  0 

2  2  E  F  ''  b  *  E  C  t  J  0 

2  2  F  2  r .  I 


3  KDOS  Ff  k  aT  Ta-LE  G F  0  S 

23  ^  b  b  7  h  Q 

TG  f  S  123^5^7^9''  LC 

9  11  <mi  OF  * 

0  4  0  0  0..  A 

N  3  11  0  0  o  17«  A 

013  .  t 

1  1  «  E‘ 


0  9  D  0  S  F  0  B .  • .  k  T  TA-lE  G  F  0  fa 

2  3  U  $  b  7  b  ° 

TG  S  123A*F)h7r9  0  lC 

1  '5 


* 
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3.4.4.12  Edit  Table  Processing 


Summing  up  the  detailed  descriptions  and  samples  given  in  previous 
chapters,  it  can  be  stated  that  the  following  four  classes  of  functions  are 
handled  by  the  edit  tables: 

/  Format  Checks  of  all  inputs  to  the  data  base  (pass/fail  decisions 
per  data  base  element) . 

/  Logical  Checks  for  a  test  of  specified  correlations  between  selected 
data  base  entries  (pass/fail  decisions  at  the  conclusion  of  an  air¬ 
field  update) . 

/  Computed  Inputs  for  the  automatic  insertion  of  information  as  triggered 
(and  in  relation  to)  other  data  base  entries. 

/  Boolean  Searches  for  the  selection  of  individual  records  based  on 
specific  intercorrelations  of  their  information  contents. 

There  are  three  programs  for  edit  table  inputs  (RDOS) : 

FHEAD  -  Header  and  tab  settings  for  FORMAT  table  inputs. 

LHEAD  -  Header  and  tab  settings  for  LOGICAL  table  inputs. 

CEDT  -  Program  for  'wholesale'  table  inputs  via  the  card  reader. 

and  two  major  software  packages: 

ET  -  For  input  conversion,  system  loading  to  INFOS  on-line 
testing,  and  the  modification  of  specific  edit  tables. 

EPRT  -  For  the  'wholesale'  INFOS  loading  of  all  current  edit 

tables  in  RDOS  required  by  the  system  control  information 
contained  in  the  'Label  Book.' 

3.4.4.12.1  ET  -  Edit  Table  Test  Package 

The  ET  package  allows  the  functional  verification  of  all  edit  tables  as 
they  are  entered  into  the  system.  It  displays  the  actual  processing  and  re¬ 
sponse  to  various  classes  of  inputs  by  showing  in  detail  whether,  where,  and 
why  a  table  lets  correct  inputs  pass  while  incorrect  ones  are  rejected. 

The  built-in  features  serve  two  functions:  (1)  that  of  proper  table  de¬ 
sign  with  an  implicit  training  of  those  analysis  who  are  responsible  for 
establishing  and  maintaining  these  system  controls  and  (2)  that  of  verifying 
and  documenting  the  editing  functions  as  originally  laid  down  in  the  document 
AAFIF  Edit  Requirements,  December  12,  1977. 
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The  edit  table  evaluation  programs  used  by  the  Air  Facilities  On-Line 
System  are  a  subset  of  the  ET  package.  Essentially  the  special  test  input 
and  documentation  features  are  removed  while  the  table  evaluation  logic 
remains  the  same.  In  ths  way  it  is  guaranteed  that  the  editing  functions 
of  the  On-Line  System  are  identical  with  those  of  the  special  test  and 
verification  package  ’ET’. 

Initialization  Sequence: 

DIR  NEHL  ;  get  directory 

ET  ;  load  ET  program  package 


System  Response: 

ENTER  FILE  NAME  FOR  STORING  THE  ON-LINE  SESSION 
START  FILE  NAME  WITH  S—  "  '  ” 


If  a  new  file  name  is  entered  in  the  space  provided  (’’’’’) 
a  new  file  will  be  created  for  storing  the  on-line  test  session. 
If  an  old  file  name  is  entered,  the  old  file  will  be  appended 
(added  on) . 

Although  any  entered  filename  (not  used  for  another  purpose) 
would  be  acceptable,  it  is  recommended  to  begin  all  session 
file  names  with  'S',  and  to  use  the  second  character  for 
identification  of  the  systems  analyst.  In  this  way  a  CLI 
command  for  a  sorted  listing  of  all  session  files  can  readily 
be  obtained. 

For  example: 

LIST/S  SN-  ;  Sorted  list  of  all  session  files 

of  analyst  ’N' 

SN01 

SN02  ;  The  possible  system  response 

SN03  would  indicate  that  'N'  has  three 

session  files  in  the  system. 

’ SN04 ’  would  be  the  next  ’new'  filname  for  analyst  'N'. 

In  the  case  of  inconsequential  or  ’play’  sessions,  use  of  a 
common  filename,  e.g.,  SPLAY  is  recommended.  This  allows 
periodic  deletions  and  thus  avoids  the  proliferation  of  in¬ 
consequential  files  kept  on  disk.  The  command  DELETE  SPLAY 
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at  the  beginning  of  a  session  would  remove  previous  contents 
and  make  'SPLAY'  a  'new'  file. 


Output 

A  complete  RDOS  back-up  file  of  the  on-line  session  will  be 
created  by  the  ET  package.  This  back-up  may  be  used  for 
subsequent  viewings  at  the  Datagraphix  terminal  by  entering 
the  CLI  command: 

TYPE  SN04  tfilename) ; 

or  the  production  of  a  hardcopy  printout: 

PRINT  SN04  (filename). 

The  printout  can  be  used  as  a  detailed  working  paper  for 
(off-line)  inspections,  improvements,  table  changes,  and 
preparation  of  the  next  on-line  session  at  the  system  analyst's 
desk.  Such  use  could  significantly  alleviate  a  crowded  terminal 
schedule,  and  could  improve  both  speed  and  quality  of  the 
'next  session'  by  allowing  for  a  better  preparation  than  would 
otherwise  be  possible. 

All  tables  tested  during  an  on-line  session  will  automatical- 
ly  be  loaded  to  INFOS  for  system  use.  A  printout  of  the 
last  test  session  (for  a  particular  table)  should  consequently 
be  kept,  serving  as  a  system's  load  and  test  evaluation 
document. 

Tables/Fi'les  Accessed 

A  logical  record  of  the  Air  Facilities  System  has  about 
650  database  elements,  comprised  of  approximately  575 
’fixed  format’  and  75  ’free  text'  items.  As  a  consequence, 
there  will  be  about  575  format  tables  in  the  operating  AF 
system  for  editing  each  updated  or  newly  entered  fixed  format 
item. 

In  addition,  there  will  be  about  60  logical  tables  for  the 
automatic  insertion  of  'computed  inputs',  or  for  testing 
whether  the  correlation  of  several  database  elements  are 
within  prescribed  bounds  and  follow  specified  rules  (i.e., 
make  sense) .  While  the  format  tables  test  each  entry  immed¬ 
iately  upon  completion  in  the  operating  AF  system,  the  logical 
tables  will  be  tested  only  at  the  end  of  a  record  update  (i.e., 
when  a  new  logical  record  is  requested  by  the  user) . 
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All  format  and  logical  tables  are  entered  as  RDOS  files. 

They  can  be  displayed,  tested,  changed  and  reloaded  to  INFOS 
individually  through  the  Edit  Table  program  ET  (for  a  whole¬ 
sale  loading  of  edit  tables  see  program  package  EPRT) . 


System  Diagram 
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3.4.4.12.2  EPRT  -  Edit  Table  Sy steins  Loadin' 


This  program  package  converts  into  the  final  form  and  loads  all  format 
and  Logical  edit  tables  as  required  by  the  Label  Book  load  module  ' INLABEL 1 . 
Tt  detects  missing  tables  and  formal  table  input  errors. 

5esides  the  loading  to  INFOS  two  output  files  'ETLIST'  and  1 EREPRT ' 
are  created. 

'ETLIST'  provides  a  comprehensive  checklist  of  leaded  and  massing 
tables.  'EREPRT'  prints  the  RDCS  names  of  all  tables  that  have  been  loaded 
along  with  detected  formal  table  errors.  If  the  print  option  (display 
request  at  the  start  of  the  run)  is  invoked,  the  full  edit  table  will  also 
be  printed.  Format  tables  are  printed  on  the  left,  Logical  tables  on  the 
right-hand  side  of  the  printout. 
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3.4.5  Tables  for  Interactive  Communications 

The  interactive  section  of  the  Air  Facility  system  performs  the 
function  of  permitting  the  user  to  access  system  on-line  capabilities. 
Basically  it  consists  of  a  sequence  of  displays  printed  at  the  Data- 
graphics  132A  terminal.  These  displays  request  information  from  the  user 
regarding  system  function  selection,  parameter  insertion,  data  entry,  as 
well  as  present  error  message  display  and  further  selection  processing. 
Responses  by  the  user  are  entered  by  depressing  the  appropriate  key(s)  at 
the  keyboard. 

To  perform  these  capabilities  the  following  software  modules  have 
been  implemented: 

o  A  Display  Generator 

o  A  Character  Read/Echo  Module 

o  A  set  of  logical  error  check  modules 
o  An  Error  Communications  Display  Generator 

Of  these  modules,  the  Display  Generator  and  the  Error  Communications 
Display  Generator  make  extensive  use  of  tables.  The  data  contained  in  these 
tables  implement  important  program  control  functions.  For  this  reason, 
their  use  and  content  is  outlined  in  this  section. 

3. 4. 5.1  Display  Generator 

The  Display  Generator  is  a  generalized  software  module  that  prints 
display  text  on  the  Datagraphics  terminal.  Its  major  capability  is  to  be 
able  to  print  any  text  stored  in  a  formatted  disk  file,  thus  separating 
text  from  a  source  program.  The  macro  algorithm  for  the  module  is  as 
follows : 


Transfer  dis¬ 
play  file  to 
' core ' 


The  indices  for  the  displays  are  stored  in  a  sequential  access  file 
with  the  following  characteristics: 


Record 


I 


Byte 


2-3 


4-6 


7-9 


Byte  1  -  character  representing  the  particular  application  area, 
e.g.,  update,  retrieval 

Bytes  2-3  -  character  representing  the  particular  display  that 
is  within  an  application 

Bytes  4-6  -  characters  representing  the  record  number  in  the 

direct  access  files  where  the  particular  display  text 
starts 

Bytes  7-9  -  characters  representing  the  record  number  in  the 

direct  access  file  where  the  particular  display  text 
ends . 

For  example: 


Sequential 
Index  File 
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The  records  that  logically  represent  a  display  are  stored  on  the 
Direct  Access  Text  File  as  follows: 

START 


HEADER 

1-4  5-6 

7-8 

9-40 

41-46 

47-52 

52-54 

TEXT 

1-40 

4  -46 

47-52 

52-54 

END 

The  start  or  initial  record  is  the  header  record.  It  is  arranged 
as  follows: 

Bytes  1-4  -  Display  ID 

Bytes  5-6  -  Number  of  physical  records  in  a  logical  display  record. 

Bytes  7-8  -  Number  of  'reads'  to  be  performed  from  this  display. 

Bytes  9-40  -  Display  header  information,  e.g.,  'AIR  FACILITY  UPDATE. ' 

Bytes  41-46  —  Cursor  position  on  the  Datagraphics  screen  where  the 
bytes  are  to  be  printed. 

Bytes  47-52  -  The  cursor  position  where,  if  required,  a  read  or  data 
input  rs  to  occur.  If  not,  it  is  filled  with  'X's.' 

Bytes  52-54  -  The  number  of  characters  to  be  inputed  if  a  read  is  to 
occur. 

The  actual  text  of  the  display  is  stored  in  records  header  +1  to  the 
end  as  follows; 

Bytes  1-40  -  display  text. 

Bytes  41-54  -  same  as  above. 

3. 4. 5. 2  Direct  Access  Test  File 

A  small  section  of  the  implemented  Direct  Access  Text  File,  named 
DISPL.DT,  is  presented  on  the  following  page. 


rfcoro 


the 


C + - 1 - + - 2 - + - 3  -  - 

0201  0503M'5  EACH  ITY  DFLFTE 
TO  DFLE  T  F  fc]PF1ELD  ENTER  : 

wac  MUmBFR : _ *  *  *  * 

I  NST  all  a  t  j  n  n  uumbep: . . . 

PASSWORD _ ■ _  - . 

O2030301AK  FACILITY  DELETE 
nEPRFSS  T H r  rp  KFY  Tn  DELETE  THE 

OR  f  E N T E D  a  R  to  RETURN: _ * 

0  1  0  ]  l  3  0  2  a  I  R  FATUITY  LnT-n^ 

*  *  *  'A  F  L  C  0  F*  E  T°  THR  AIR  F  ACUITY  OFT4 
CEMENT  SvSTEm*  *  * 
for  requested  Tata  enter  THE 
KEYS, '.‘.'HE4'  FU’I^HFD  ENTER  THE 
TO  correft  The  L  a  5  T  TH4RactER  F N T e r 

*  X  '  KEY. 

TO  CORREFT  KE  FULL  FIFlO  ENTRY  FtvTER 
THF  'SHIFT  V '  KEY. 

TO  ESCFRF  f;,TRY  FIvTER  ThF  'SHIFT  !'  KEY 

to  a f c f s s  system  functions: 

FiviTER  y o o R  G F c  - U  : _ '  ' 

FNTEP  voor  p  a  .sS-'-opo  :  . . 

0  1  02°90  1  S  E  I.  E  r  T  A  T  F  FACTLTTY  FUNCTION 
PLEASE  SFlF(T  T^f  FiiNlUIor  you  t\TSH  TO 
PERFORM 

1  OISPLAY  DATA  5 

?  UPDATE  DATA  o 

3  RETRTFVE  DATA  7 

0  ADO  A  AIPFTFLO  6 

ENTER  THF  NIP'BFR 
CHOICE  _ ' 

01  030801 SEL ECT  ATR  FACTLTTY  FUNCTION 
PLFASE  SFLFCT  T  Hp  FUNCTION  YOU  WISH  TO 
PERFORM 
1  UPDATE  0»TA 
?  OISPLAY  oata 
3  ado  A  PE  r0o0 

ENTER  THC  m  u  m  h  F  R  CORPESPONniNG  TO  YOUR 
CHOKE _ ' 

0]  09090]  «=  E  I  EFT  ATR  FACUITY  FUNCTION 
PLFASE  SplFCT  THF  FUNCTION  YOU  wTSH  TO 


dfl  etf 
output 

(HIT  P|IT 
LnG-OF  F 
CORPESPONOl NG  TO 


PE  pF  orm 
1  UP????  DATA 

?  D1SPIAY  OATa 
3  AOO  A  RECORD 

0  delete  A  EFCORO 

FNTER  THP  NLiRBFR  CORRESPONDING 

CHOICE _ ' 


0 - + - 5 - 

o  o  ?  o  o  l  x  x  y  x  v  x  o  o 
0  0  5  0  2  1  X  X  Y  X  y  x  o  0 

°07  02  1  °07  °07  0*j 
009021 O0R0a5Ofc 

oi i o?ivyyyyyoo 
oopoaivxyxvxoo 
oosopixxxxxxoo 

007021 O070F1 0) 

00200 i xxy xxxoo 
MANAOOU029yxXXVXOO 
0  0  o  0  8  9  X  x  X  x  x  x  0  0 
appropriate0 o«ORiyx xx xxoo 
RETURN  KEY.O0P0S2YxyXXX00 

oi oopfcyxxxxxoo 
oi ooGfcyyxxxxoo 
012026XXVXXXOO 
o  1 2  o  s  s  y  x  x  x  v  x  o  o 
,01  on?fexx xx xx°0 

018021 XXXXXXO0 
0  2  0  0  3 1  02008202 
022031 02205808 
o  0  2  0  o  1 XXXXXXO0 
01)0021  XXXXXXOO 
00O080XXXXXXO0 
0  0  8  0  P  1  XXXXXXOO 

00*02ivxvxxx00 
01  0021  vyxxxxoo 

0 1 2021 XXXXXXOO 
01  8  0  p 1 yyy XXXOO 
0  1  8  0  8 1  0 1  8 0  7301 
002021 XXXXXXOO 
000021 XXXXXXOO 
0  0  0  0  8  0  X  X  X  X  x  X  0  0 
008028X XYXVXO0 
°0«028XXXXXX00 
°1 0028XXXXXXO0 
01 P021 XXXXXXOO 
01208001 201501 
0  0  2  0  P 1 XXXXXXOO 
000021 XXXXXXOO 
nooOAQXXXXXXOO 
OO8OP6XXXXXXOO 
008028VXVXXXO0 
01 0028XXXXXX00 
°l?0?bXXXXXXPO 
O1O021XXXXXX00 
0]  AJ  0  8  0  0  1  007001 


DAT4 

FORMAT 


YOUR 


% 

1 


>• 


Tn  YOUR 


8  z 

Z3 
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3 . 4 . 5 . 3  Error  Communications  Display  Generator 

The  Error  Communications  Display  Generator  is  a  generalized  software 
module  that  prints  error  messages  and  'Further  Action'  prompts  on  the 
Datagraphics  screen.  It  is  accessed  when  a  user  inserts  an  invalid  response 
to  a  prompt  or  when  he  enters  'shift  ■  1  in  character  input.  The  macro 

algorithm  for  the  module  is  as  follows; 


v 


AD-A076  106 


UNCLASSIFIED 


SYNECTICS  CORP  ROME  N  Y  F/«  9/2 

AUTOMATED  AIR  INFORMATION  PRODUCTION  SYSTEM,  PHASE  I.  VOLUME  II— ETC(U) 

SEP  79  N  NEHL  »  P  MOULDER  F3060F-77-C-006S 


RADC-TR-79-179-V0L-3 


TABLE  DRIVEN  DISPLAY  AND  INPUT  FUNCTIONS 


ENTER  YOUR  GEO-ID: _ " 

ENTER  YOUR  PASSWORD  : . . . 


01  020901  SELECT  AIR  FACILITY  FUNCT 
PLEASE  SELECT  THE  FUNCTION  YOU  WI 
PERFORM 

1  DISPLAY  DATA  5  DELETE  A 

2  UPDATE  DATA  6  OUTPUT  F 

3  RETRIEVE  DATA  7  OUTPUT 

4  ADD  A  RECORD  8  LOG-OFF 


j  ENTER  THE  NUMBER  CORRESPONDING  TO 
CHOICE  : _ ' 


01030801SELECT  AIR  FACILITY  FUNCT! 
PLEASE  SELECT  THE  FUNCTION  YOU  WI< 
PERFORM 

1  UPDATE  DATA 

2  DISPLAY  DATA 

3  ADD  A  RECORD 

ENTER  THE  NUMBER  CORRESPONDING  TO 
CHOICE _ ' 


020031 
022031 
ION  002041 
SH  TO  004021 
004C60 
RECORD006021 
ORMAT  008021 
010021 
012021 
YOUR  016021 
016061 


ION  002021 
SH  TO  004021 
004060 
006026 
008026 
010026 
YOUR  012021 
012060 


YOUR 


02006202 

02205306 


XXXXXXOO 

XXXXXXOO 

XXXXXXOO 

XXXXXXOO 

XXXXXXOO 

XXXXXXOO 

XXXXXXOO 

xxxxxxoo 

01607301 


xxxxxxoo 

xxxxxxoo 

XXXXXXOO 

xxxxxxoo 

xxxxxxoo 

xxxxxxoo 

xxxxxxoo 

01201501 


FUNCTION/AREA  IDENTIFICATION 


•  DISPLAY  TITLE 


•  DISPLAY  TEXT 


•  DISPLAY  SCREEN  POSITIONING 


CURSOR  POSITIONING 


CHARACTER  INPUT  CONTROL 
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The  indices  for  the  displays  are  stored  in  a  sequential  access  file 
with  the  following  characteristics: 


Byte  1  -  character  representing  the  particular  application  areas,  e.g., 
update  retrieval. 

Bytes  2-3  -  characters  representing  the  particular  display  that  is 
within  an  application. 

Bytes  4  -  character  representing  the  particular  error  display  for  a 
display. 

Bytes  4-7  -  characters  representing  the  record  in  the  direct  access 
file  where  the  particular  error  text  starts. 

Bytes  8-10  -  characters  representing  the  record  number  in  the  direct 
access  file  where  the  particular  error  text  ends. 

For  example: 


Direct  Access  File 


C - + - 1 

201 1001003 
20 i ?oo«oo6 
2021007009 

101  1010  01c?  Index  File  INDI S  . DT 

!  1012013016 

1021017019 
4021 020022 
6012023025 


603102602b 
601 1 0?9«31 
7011 032030 
7012036OOO 

20100010*40 

7013035037 
601  3005  0  0b 
6010009052 
7010053055 
7  0 1  505605b 
701 6059061 
7017062060 
7018 0b5 067 
7019066070 
7021071073 
7022070076 
7  023077o60 
7020061060 
7  025065066 
7  026090093 
70270944097 
6013096100 
3011101103 

3. 4. 5. 4  Error  Text  File 

The  records  that  logically  represent  an  error  area  are  stored  on  the 
direct  access  file  as  follows: 

START 


END 


The  start  or  intial  record  is  the  header  record.  It  is  arranged  as 
follows : 

Bytes  1-4  represent  the  error  area  ID. 

Byte  5  represents  the  number  of  available  'Further  Action'  options. 
Bytes  6-40  represent  error  message  text. 

Subsequent  records  store  error  message  text. 


Bytes  1-4  represent  the  error  area  ID. 

Byte  5  represents  the  number  of  available  ’Further  Action'  options. 
Bytes  6-40  represent  error  message  text. 


Subsequent  records  store  error  message  text.  The  following  is  a  sample  of 
the  first  part  of  the  Error  Text  File,  loaded  to  the  system: 


C - + - 1 - + - 2 - + - i - + - 

20  1  1 2*  *  I N  VALID  -.At 
DO  1  RE-ENTER  WAC 

2  RETURN  TO  FuwC  T  I  UN  DISPLAY 
20 123***  AC /IK’S.  DOES  MU  "AfCH  GEO-ID 
DO  RE-ENTER  1  wAC/INS.  2  GEO -ID 

3  EXIT  AIK  FACILITY  SYSTEM 
202 1 2* *  I NCORREC T  DELETE  PASSWORD 
DO  1  RE-ENTER  DELETE  PASSWORD 

2  RETURN  TO  FUNCTION  DISPLAY 

i  on  2**  invalid  geo-id 
DO  1  RE-ENTER  GEO-ID 

2  EXIT  A]P  FACILITY  SYSTEM 
1 0 1 23* *  I NV ALID  PASSWORD 
DO  1  RE-ENTER  PASSWORD 

2  RE-ENTER  GE  0- 1 D  AND  PASSWORD 

3  EXIT  AIR  FACILITY  SYSTEM 
1 021 2*** INCURRE CT  RESPONSE 

DO  1  RE -SELF  CT  FUNCTION 

2  EXIT  AIR  FACILITY  SYSTEM 
40212**1 N CORRECT  RESPONSE 
DO  1  RE-SELECT  RESPONSE 

2  RETURN  TO  FUNCTION  DISPLAY 

b0122**INVALID  CATEGORY 
DO  1  RE-SELECT  CATFGORY 

2  RETURN  TO  ThE  FUNCTION  DISPLAY 
60312**]NVAL1Ii  SUM -CATEGORY 
DO  1  RE-SELECT  SUM-CATEGORY 

2  RETURN  TO  THE  FUNCTION  DISPLAY 
f>01  12**  1NV  ALU*  RESPONSE 
DO  1  RE-ENTER  PFSPONSE 

2  RETURN.  TU  THE  FUNCTION  DISPLAY 

701 lb**INCORRFCT  ENTRY 
DO  1  RE-ENTER  RESPONSE  2  RETURN 

3  NEXT  FIELD  4  COPY  5  NE*  DATA  b  SAVE 
701 3b**FND  OF  PAGE 
DO  1  TEXT  2  RETURN 

3  COPY  4  CONTINUE  S  N’E*  DATA  6  SAVE 
70123**FURTHER  MULTIPLES 
DO  1  PROCFSS  NEXT  MULTIPLE 

2  DON'T  PROCESS  MULTIPLE  3  COPY 
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20143**]  NVALI  I1  INST  ALL  AT  It'* 

DO  1  RE-ENTER  i'AC 

2  Rf-EMEO  INSTALLATION 

3  RETURN 

60133**1 N VALID  SUB-CATEGORY 
DO  1  RE-ENTER  CATEGORY 

2  RE-ENTER  SUP-CaTEGORY 

3  RETURN  TO  FUNCTION  DISPLAY 
60144** INVALID  ELEMENT (5) 

DO  RE-ENTER:  1  CATEGORY 

2  SUB-CATEGORY 

3  ELEMENTS  4  return 
70145**END  OF  PAGE 

DO  1  TEXT  2  RETURN 

3  COPY  4  CONTINUE  5  N  E  iV  DATA 
70153**END  OF  PAGE 
DO  1  CONTINUE  2  RETURN 

3  COPY 

701fc2**FILE  ALREADY  EXISTS 
DO  1  FNTER  K  F  X-  FILE  NAME 

2  RE  TORI  TO  FUNCTION  DISPLAY 
701  72**FILE  DOESN’T  EXIST 
DO  1  fcNTER  F  ■  E w  FILF  NAME 
2  RETURN 

7 0 1 B2* *  I NV AL I D  SUP-CATEGORY 
DO  1  RE-EnTEW  SUr-CATEGORY 

2  RETURN  TO  FUNCTION  DISPLAY 
70194**]NCORRECT  ENTRY 

DO  1  RE-ENTER  RESPONSE  2  RETURN 

3  NEXT  FIELD  4  CUPY 

70212**1 N CORRECT  START  COLUMN 

DO  1  RE-ENTER  START  COLUMN 

2  RETURN  TO  FUNCTION  DISPLAY 
70222**ELEMEMS  DO  NOT  HAVE  SORT  KEY  1 
DO  1  RE-ENTER  ELEMENT 

2  RETURN  TO  FUNCTION  DISPLAY 
70233**L AT ITUOE  OUT  OF  RANGE 
DO  1  RE-ENTER  LATITUDE 

2  PE-SELECT  OFLIMITJNG  CRITEREA 

3  R  F  TURN  TO  FUNCTION  DISPLAY 
70243**1 ONGTJTUDE  OUT  OF  RANGE 

DO  1  RE-ENTER  L  ONG  T I T  UDE 

2  PE-SELECT  DELIMITING  CRITEREA 

3  RETURN  TO  FUNCTIONS  DISPLAY 
70254** MINUTES  UUT  OF  RANGE 

DO  1  RE-fN'TFR  MINUTES 

2  RE-ENTER  LAT/LONG  3  RETURN 

4  RE-SELECT  DELIMITING  CRITEREA 

5  RETURN  TO  FUNCTIONS  DISPLAY 
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3.4.6  On-Line  Programs 


The  on-line  capabilities  of  the  Air  Facilities  Subsystem  are  supported 
by  special  on-line  programs,  series  of  tables  with  software  characteristics 
in  function  areas  vital  to  the  user,  and  interactive  modules  for  the  handling 
of  basic  display  and  input  functions.  The  special  on-line  software  is  out¬ 
lined  in  greater  detail  in  this  section.  It  provides  a  program  framework 
that  enables  the  data  base  management  funcions  of: 

o  System  Security  with  Log/on,  Log/off  procedures, 

GEO-ID/Fassword  checks  and  their  correlations. 

o  Lata  Retrieval  from  the  AAFIF  data  base  and  display 
on  a  page-by-page,  group,  or  element  level. 

°  Updates  with  extensive  format  and  logical  checks, 
including  automatic  updates  (computed  inputs) . 

o  Adds  and  Deletes  of  the  ir.f ormation  for  a  whole 
airfield . 

The  programs  for  the  on-line  data  base  management  system  consist  of  the 
following  modules: 

3  4  6.1  AFF  ~  Air  Facilities  Executive 

The  program  AFF  serves  as  the  on-line  Air  Facilities  executive 
and  performs  the  functions  of  Log-on/Log-off.  The  interactive, 
on-line  mode  provides  for  a  full  repertoire  of  error  checking  of 
user  inserted  data  as  well  as  a  complete  retinue  of  meaningful, 
diagnostic  error  messages  with  a  unique  steering  capability  to 
allow  the  user  to  act  upon  these  errors. 

The  program  initially  asks  the  user  -to  enter  a  GEO-ID  and  pass¬ 
word.  These  values  serve  as  "keys"  to  enter  the  program  which 
then  accesses  a  subroutine  that  asks  a  user  to  select  a  system 
function.  The  functions  include  ADD,  DELETE,  UPDATE,  DISPLAY, 

RETRIEVE ,  and  LOG-OFF.  It  then  will  initate  the  execution  of 
the  selected  function.  Upon  completion  the  user  will  have 
the  option  of  re-selecting  a  function. 

Input 

The  inputs  to  the  AFF  program  are  the  entrance  'keys'  of  the 
GEO-ID  and  password  as  well  as  the  selected  function. 


Output 

The  outputs  from  the  program  are  the  updated  user's  log 
as  well  as  a  completed  function. 


/ 


'ijry  r  j,  'V  t.  ' 
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Tables/Files  Accessed 


I 
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The  following  tables/files  are  accessed  by  the  program: 
/  Validate  GEO-ID  and  password: 

VGEO.DT 

/  Transaction  Log: 

TLG . DT 

/  Display  File  and  Indices: 

DISPL.DT 

INCD.DT 

/  Communications  File  and  Indices 


CTL.DT 

INCT.DT 


/ 

FDO — | 

DLE 

if 

DLEl-1 

/ 

UPDl  - 

UPD2 

UPD3 

/  Password  File 

"QXFA" 

Major  Subroutines 

The  major  subroutines  of  the  program  are: 

Where  the  user  selects  the  function  to  be 


UPD31 

LFPD32 

UPD4 

UTXT 

UTXTS 

UTXTA 

CHSTRG 

STRSCH 

UPD5  — 
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START 


System  Diagram 


/Add 

/Display 

/update 


/Retrieve 

/Log-Off 


3. 4. 6. 2  DISPLAY 


The  Display  Subroutines  permit  a  user  to  display  and  view  selected  con¬ 
tents  of  an  Air  Facilities  record.  The  program  initially  asks  the  user  to 
enter  the  WAC  and  installation  numbers.  These  parameters  serve  to  identify 
the  record  to  be  displayed.  The  program  then  asks  the  user  to  select  the  por¬ 
tion  of  the  record  that  he  desires  to  display.  The  full  record,  a  full  cate¬ 
gory,  a  full  subcategory  of  a  category,  specific  elements,  or  a  range  of 
elements  may  be  chosen.  Next  the  user  is  given  the  choice  of  having  the 
programs  displayed  at  the  terminal  or  the  line  printer  or  both.  If  the  line 
printer  option  is  selected,  the  selected  portions  of  the  record  are  printed 
in  sequence  at  the  line  printer.  If  the  terminal  option  is  chosen  the  program 
displays  all  data  items  selected,  if  necessary  on  a  page-by-page  basis.  Due 
to  their  character  lengths,  text  fields  are  processed  in  separate  displays. 
Upon  completion  the  user  is  asked  if  he  desires  to  continue.  If  so,  the  above 
process  is  repeated. 

Input 

The  inputs  to  the  program  are: 

/  User  inserted  parameters  that  are  the  retrieval  indexes  for  the  record, 
i.e.,  WAC  and  Installation  Number. 

/  The  positional  parameters  that  specify  which  portions  of  the  record 
are  to  be  displayed,  i.e.,  the  full  record,  a  category,  a  subcategory 
of  a  category,  specific  elements,  or  a  range  of  elements. 

/  The  actual  data  in  the  record  that  is  to  be  displayed. 

Output 

The  output  from  the  program  is  the  display  of  data  on  the  screen  or  a 
printout  of  the  data  at  the  line  printer. 
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3. 4. 6. 3  UPDATE 

The  Update  subroutines  permit  a  user  to  update  selected  contents  of  an 
Air  Facilities  record.  The  program  initially  asks  the  user  to  enter  the  WAC 
and  installation  numbers.  These  parameters  serve  to  identify  the  record  to  be 
updated.  The  program  then  asks  the  user  to  select  the  portion  of  the  record 
that  he  desires  to  update.  The  full  record,  a  full  category,  a  full  sub¬ 
category,  specific  elements,  or  a  range  of  elements  may  be  chosen.  The  pro¬ 
gram  then  sequences  through  the  selected  portion  of  the  record.  At  each  page 
the  present  contents  of  the  data  elements  are  printed  and  the  user  simply 
inserts  the  desired  changes.  These  inputs  are  made  subject  to  format  checks 
with  corrective  actions  requested  by  the  system  when  necessary. 

Text  fields,  due  to  their  character  lengths,  are  processed  following  the 
regular  page  update.  Upon  completion  of  this  process,  logical  checks  are 
performed  that  correlate  the  entered,  new  data  with  other  data  elements  of 
the  airfield.  If  correct,  the  update  process  will  be  completed  by  automati¬ 
cally  writing  the  new  data  to  the  data  base.  Otherwise,  the  user  will  be 
notified  by  the  system  for  remedial  actions.  Finally,  the  user  is  asked  if 
he  desires  to  update  another  record.  If  so,  the  above  described  process  is 
repeated. 

Input 

The  inputs  to  the  program  are: 

•J  User  inserted  parameters  that  are  the  retrieval  indexes  for  the 
record,  i.e.,  WAC  and  installation. 

/  The  positional  parameters  that  specify  which  portions  of  the  record 
are  to  be  updated,  i.e.,  the  full  record,  a  category,  a  subcategory 
of  a  category,  specific  elements,  or  a  range  of  elements. 

■J  The  actual,  current  data  in  the  record  that  is  to  be  updatec 
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Output 

The  output  of  the  Update  program  is  the  user  inserted  values  that 
replace  the  old  element  values. 

Table  s/F i les 

The  followino  tables/files  are  accessed  by  the  Update  programs: 

/  Air  Facilities  data  base 
J  Label  Book  Tables 
/  Format  and  Logical  Check  Tables 
/  WAC  Validation  File:  VWC.DT 

/  Category/Subcategory /Element  Validation  File:  VPP.DT 
/  Display  File  and  Indices:  DISPL.DT 


INCD.DT 

/  Cojnmuni cation  File  and  Indices:  CTL.DT 

INCT.DT 


3. 4. 6. 4  ADD 


The  Add  Programs  permit  a  user  to  insert  or  add  a  full  Air  Facilities 
record  to  the  data  base.  The  program  initially  asks  the  user  to  insert  the 
record  index  parameters  of  WAC,  installation  number,  and  coordinates.  The 
program  then  pages  through  each  page  of  elements  of  a  subcategory  of  all 
categories.  Due  to  their  character  lengths,  text  fields  are  processed 
following  the  addition  of  regular  page  element  fields.  Upon  completion  of 
entering  a  record  the  program  will  interactively  ask  if  the  user  desires  to 
enter  another  one.  If  so,  the  above  described  process  is  repeated. 

Input 

The  inputs  to  the  program  are  the  data  inserted  by  the  user  via  keyboard 
entry.  There  are  two  types: 

/  Input  parameters,  that  are  the  index  parameters  for  the  record.  They 
include  WAC,  installation,  and  geographic  coordinates. 

/  Record  data  that  is  the  field  element  data  including  text  that  the  user 
inserts. 

Output 

The  output  from  the  program  is  a  full  Air  Facilities  record  that  may  be 
further  updated  or  accessed  by  other  Air  Facility  capabilities. 

Tables/Fi les 

The  following  table/files  are  accessed  by  the  ADD  program: 

/  Air  Facilities  data  base 

/  LABL  'book':  LABL 

/  WAC  Validation  File:  VWC.DT 

/  Category/Subcategory/Element  Validation  File:  UPP.DT 

/  Display  File  and  Indexes:  DISPL.DT 

INCD.DT 
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J  Communication  File  and  Indices:  CTL.DT 

INCT.DT 

/  Format  and  Logical  Test  Files:  FMT.DT 

LGT.DT 

As  with  the  previously  discussed  Update  program,  format  checks  will  be 
conducted  by  the  system  upon  completion  of  each  data  field.  The  logical  check 
will  commence  only  after  data  for  all  elements  in  the  airfield  have  been 
entered. 


3. 4.6. 5  DELETE 


The  Delete  Subroutines  permit  a  user  to  delete  an  Air  Facilities  data 
record.  It  is  performed  in  an  interactive,  on-line  mode.  It  provides  for  a 
full  repertoire  of  error  checking  of  user  inserted  data  as  well  as  a  complete 
retinue  of  meaningful  diagnostic  error  messages  and  unique  steering  capability 
to  allow  the  user  to  act  upon  these  errors. 

The  program  initially  asks  the  user  to  enter  WAC  and  installation  numbers. 
These  parameters  serve  to  identify  the  record  to  be  deleted.  The  program  then 
asks  the  user  to  enter  or  delete  password.  The  user  is  given  only  three 
chances  to  correctly  enter  the  password.  Then  the  record  is  deleted  and  the 
user  is  informed  via  a  display  of  such.  The  user  may  also  delete  a  multiple 
element  value.  He  simply  inserts  the  field  identifier,  and  then  the  mulitple 
number. 

Input 

The  inputs  to  the  program  are  the  WAC  installation  record  identifiers 
and  the  record  to  be  deleted. 

Output 

The  output  from  the  program  is  the  deleted  record. 

Tables/Files  Accessed 

The  following  are  the  tables/files  accessed  by  the  DELETE  program: 

/  Air  Facilities  data  base 

/  WAC  Validation  File:  VWC.DT 

/  DELETE  Password  File:  QXZH 

J  Display  File  and  Indices:  DISPL.DT 

INCD.DT 

/  Communication  File  and  Indices:  CTL.DT 

INCT. DT 


3. 4. 6. 6  RETRIEVE 
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The  RETRIEVE  programs  permit  a  user  to  retrieve  Air  Facility  records 
according  to  user  specified  parameters.  It  provides  for  a  full  repertoire 
of  error  checking  of  user  inserted  data  as  well  as  a  complete  retinue  of 
meaningful  diagnostic  error  messages  and  a  unique  steering  capability  to 
allow  the  user  to  act  upon  these  errors. 

The  parameters  are  initially  a  table  that  creates  a  Boolean  query  logic. 
These  tables  are  then  delimited  to  the  full  data  base,  a  geographic  grid 
area,  a  VJAC  range,  country  range,  installation  range,  or  list  of  previously 
retrieved  records.  The  program  then  will  retrieve  the  records  and  pass  them 
to  an  output  module.  The  program  is  entitled  RTL  and  is  called  from  the  LOG 
program.  It  is  stored  in  the  file  RTL.FR,.  Its  binary  code  is  stored  in  the 
file  RTL. RB  and  the  RLDR  sequence  is  stored  in  the  file  RTL.MC.  It  is,  of 
course,  stored  in  the  AF  Directory. 

Input 

The  inputs  to  the  RETRIEVE  program  are  the  user  inserted  and  created 
Boolean  logic  table,  and  search  delimiters.  These  include  WAC  range,  installa¬ 
tion  numbers,  grid  area,  previous  subset,  country  range,  or  full  data  base. 

Output 

The  output  from  the  program  is  the  set  of  retrieved  records. 

Tables/Files  Accessed 

The  following  are  the  tables/files  that  the  program  accesses: 

/  Boolean  Logic  Table:  R-  . DT 

/  GRID  Search  File:  GRID 

RFLWC 

/  WAC  Validation  File:  VWAC.DT 

RFWC.DT 

J  Any  specified,  previously  derived  subset:  -  .DT 
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3. 4. 6. 7  Interactive  Modules 


The  interactive  section  of  the  Air  Facility  system  performs  the  function 
of  permitting  the  user  to  access  system  on-line  capabilities.  Basically,  it 
consists  of  a  sequence  of  displays  printed  at  the  Datagraphics  132A  terminal. 
These  displays  request  information  from  the  user  regarding  system  function 
selection,  parameter  insertion,  data  entry,  as  well  as  present  error  message 
display  and  further  selection  processing.  Responses  by  the  user  are  entered 
by  depressing  the  appropriate  key(s)  at  the  keyborad. 

To  perform  these  capabilities  the  following  software  modules  have  been 
implemented: 

•  A  Display  Generator 

•  A  Character  Read/Echo  Module 

•  A  set  of  logical  error  check  modules 

•  An  error  communications  display  generator 
3. 4. 6. 7.1  Display  Generator 

The  Display  Generator  is  a  generalized  software  module  that  prints 
display  text  on  the  Datagraphics  terminal.  Its  major  capability  is  to  be 
able  to  print  any  text  stored  in  a  formatted  disk  file,  thus  separating  text 
from  a  source  program.  The  macro  algorithm  for  the  module  is  as  follows: 
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The  display  generator  is  accessed  by  a  Fortran  call  to  DISPL  (N,  Nl, 
ARRAY)  where: 

N  =  application  area 

Nl  =  display  number  in  the  application  area 

ARRAY  =  is  the  array  that  contains  the  'core'  image  of  the  disk 
file  text 

3 . 4 . 6 . 7 . 2  Read/Echo  Module 

The  Character  Read/Echo  Module  will,  as  titled,  read  and  echo  a 
character (s)  from  the  keyboard  to  the  Datagraphics  terminal.  The  module 
also  provides  cursor  positioning,  character  delete,  line  delete,  input 
escape,  and  no-echoing  of  excess  input  of  characters.  The  macro  algorithm 


(characters  to  be  read  in- 
Echo  it  to  the  terminal 
(if  greater  than  maximum 
allowable  characters  it  is 
not  echoed) . )  * 


I 


I 


The  valid  character  set  is  that  contained  in  the  AF  data  base, 
control  characters  are  as  follows: 

character  delete 


shift  ^ 
CR 

shift  m 


line  delete 
exit 

exit  and  set  flag 


Special 


The  two  independent  subroutines  that  compromise  the  module  are: 

DREAD  (ARRAY,  N,  INBUF) 
where : 

ARRAY  is  the  display  text  containing  cursor  positions  and  number 
of  characters  to  be  read  in. 

N  =  specific  line  of  display  text. 

INBUF  is  the  vector  that  contains  inputted  characters. 

RDWR  (NCHARS ,  NREAD,  INBUF) 

This  routine  does  the  actual  reading,  checking,  and  echoing. 
NCHARS  =  maximum  number  of  characters  to  be  read  in. 

NREAD  =  actual  number  of  characters  read  in, 

INBUF  =  vector  containing  characters  read  in. 

3. 4. 6. 7. 3  Error  Check  Routines 

The  logical  error  check  subroutines  determine  whether  the  user’s 
inserted  characters  are  valid  with  respect  to  the  specific  application. 
Identified  error  checks  include: 

•  WAC  Validation 

•  Installation  Validation 

•  GEO- ID/Validation  Password 
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Get  Index  to 
Control  Area 
Direct  Access 
File 


If  Character  is 
out  of  bounds  - 
reread  in  option 


Set  Option  Flag 
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•  Update  Format  Check 

•  Update  Logic  Check 

•  Positional  Parameter  Validation 

These* checks  are  implemented  via  the  use  of  subroutines  with  the  following 
format: 

Subroutine  CHECK  (INBUF,  IER) 

where : 

CHECK  =  the  name  of  the  validation  routine. 

INBUF  =  the  vector  containing  the  data  to  be  validated. 

IER  =  an  error  flag  signifying  whether  data  is  valid  or  invalid. 

The  Error  Communications  Display  Generator  is  a  generalized  software 
module  that  prints  error  messages  and  'Further  Action'  prompts  on  the  Data- 
graphics  screen.  It  is  accessed  when  a  user  inserts  an  invalid  response  to 
a  prompt  or  when  he  enters  'shift®'  in  character  input.  The  macro 
algorithm  for  the  module  is  as  follows: 
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Transfer  Text 
to  'Core' 


Print  Text 


Read  in 

’FURTHER  ACTION' 
Option 


Clear  Screen 


3. 4.6. 7. 4  Application  Principles  of  Interactive  Routines 

Use  of  the  outlined  modules  can  be  outlined  in  simplified  form  by  the 
following  sample  of  an  interactive  program  sequence: 


Call  DISPL  (1,  1,  IARR2) 


Print 

Display 


Call  DREAD  (1AKR2,  NVM, 


INBUF,  NR) 


Read  (accept)  response 
from  display  terminal 


Specific  test  program;  or 
Call  CHECK  (INBUF,  IER) 


IF  (IER. EQ.  OK)  GO  TO 


Perform  check 
on  Response 


Branch  on 
Correct  Response 


> 


In  the  case  of  error: 


Call  CNTRL  (1,  1,  1,  IRET) 

1 

IF  (IRET. EQ.  Return)  Return 


Call  RET  (IRARR2,  NUM) 
GO  TO  DREAD 


Print  Communications 
Display  and  Read  in 
Response 

Return  to  Functions 
Display 


Re-position  cursor 
and  return  to  'Call 
DREAD'  - >(^) 
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3.4.7  Error  Messages 


Two  types  of  error  messages  may  occur.  The  first  is  contained  in  the 
software  itself  and  triggered  by  a  most  unusual  condition  tested  for  and 
implemented  in  a  given  subroutine.  These  error  messages  show  up  only  in  the 
case  of  a  very  unusual  situation  to  indicate  a  system,  table,  or  software 
error. 

This  is  in  contrast  to  the  second  type  of  error  messages  as  produced 
by  the  Error  Communications  Display  Generator.  The  latter  are  table  driven 
and  part  of  an  elaborate  Interactive  Communications  Package  to  achieve  secure, 
flexible,  and  fool  proof  on-line  operations. 

3 . 4 . 7 . 1  System,  Table,  Software  Error 

The  first  type  of  error  is  program,  table,  or  system  oriented  and  should 
not  occur  at  all  in  an  operational  system.  (If  it  does,  a  more  serious  pro¬ 
blem  is  indicated,  requiring  interventions  of  systems  people  or  programmers.) 
The  error  messages  are  of  the  general  form: 

***  XXXXXX 

with  'XXXXXX'  standing  for  a  specific  message  such  as  'FORMAT  TABLE  MISSING.' 
They  will  be  displayed  on  the  screen  starting  at  the  current  cursor  position. 

3. 4. 7. 2  On-Line  Errors 

The  second  type  of  error  is  user  oriented,  expected  and  planned  for  to 
provide  a  chance  for  pointing  out  and  correcting  input  errors.  Depending  upon 
function  and  display  layout,  the  computer  generated  question  is  sometimes  just 
repeated  upon  receiving  an  invalid  input. 

In  more  complex  situations  a  specific  error  message  will  be  generated 
and  shown  at  a  communications  control  area,  along  with  the  options  available 
to  continue  processing.  The  user  need  only  enter  the  number  that  corresponds 
to  his  desired  choice  and  the  return  key. 

3 . 4 . 7 . 3  List  of  Implemented  On-Line  Messages 

‘♦Invalid  WAC 

Do  1  Re-enter  WAC 

2  Return  to  function  display 


“WAC/INS.  Does  not  match  GEO-ID  Re-enter 

Do  1  WAC/INS 

2  GEO- ID 

3  Exit  Air  Facility  System 

‘‘Incorrect  Delete  Password 

Do  1  Re-enter  delete  password 
2  Return  to  function  display 

“Invalid  GEO-ID 

Do  1  Re-enter  GEO-ID 

2  Exit  Air  Facility  System 

“Invalid  Password 

Do  1  Re-enter  Password 

2  Re-enter  GEO-ID  and  Password 

3  Exit  Air  Facility  System 

“Incorrect  Response 

Do  1  Re-select  function 

2  Exit  Air  Facility  System 

“Incorrect  Response 

Do  1  Re-select  response 

2  Return  to  function  display 

“Invalid  Category 

Do  1  Re-select  category 

2  Return  to  the  function  display 

“Invalid  Subcategory 

Do  1  Re-select  subcategory 

2  Return  to  the  function  display 

“Invalid  Response 

Do  1  Re-enter  response 

2  Return  to  the  function  display 


“End  of  page 


Do  1  Text 

2  Re  turn 

3  Copy 

4  Continue 

5  Save 

* ‘Further  Multiples 

Do  1  Process  next  multiple 

2  Don't  process  multiple 

3  Copy 

“Invalid  Installation 

Do  1  Re-enter  WAC 

2  Re-enter  Installation 

3  Return 
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“Invalid  Sub-Category 

Do  1  Re-enter  Category 

2  Re-enter  Sub-Category 

3  Return  to  function  display 


“Invalid  Element(s)  Re-enter 

Do  1  Category 

2  Sub-category 

3  Elements 

4  Return 


“End  of  Page 

Bo  1  Text 

2  Return 

3  Copy 

4  Continue 

5  New  Data 


“End  of  Page 

Do  1  Contirue 

2  Return 

3  Copy 
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“File  Already  Exists 

Do  1  Enter  a  new  file  name 
2  Return 


“File  Doesn't  Exist 

Do  1  Enter  new  file  name 
2  Return 


“Invalid  Element 

Do  1  Re-enter  Element 
2  Return 


“Incorrect  Entry 

Do  1  Re-enter  response 

2  Return 

3  Copy 


“Incorrect  Start  Column 

Do  1  Re-enter  start  column 

2  Return  to  function  display 


* ‘Elements  Do  Not  Have  Sort  Key  1 

Do  1  Re-enter  element 

2  Return  to  function  display 


“Latitude  Out  of  Range 

Do  1  Re-enter  latitude 

2  Re-select  delimiting  criteria 

3  Return  to  function  display 
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Longtitude  Out  of  Range 


Do  1  Re-enter  longtitude 

2  Re-select  delimiting  criteria 

3  Return  to  functions  display 


‘Minutes  Out  of  Range 

Do  1  Re-enter  minutes 

2  Re-enter  Lat/Long 

3  Return 

4  Re-select  delimiting  criteria 

5  Return  to  functions  display 


‘Incorrect  Direction 

Do  1  Re-enter  direction 

2  Lat/long 

3  Minutes 

4  New  criteria 

5  Return 


‘GRID  Finished 

Do  1  Further  grids 

2  New  delimiting  criteria 

3  Search 

4  Return 


3.4.8  Application  Programs 


The  Application  Programs  usually  involve  the  processing  of  larger 
sections  of  the  data  base.  For  that  reason  a  'wholesale'  off-line  processing 
during  the  off  hours  (nights,  weekends,  holidays)  is  indicated.  Nevertheless, 
the  on-line  system  is  frequently  used  to  initiate  and  to  simplify  those  off¬ 
line  procedures  (e.g.  the  on-line  creation  of  Boolean  search  tables  for  the 
off-line  processing  of  large  SAIR  requests) . 

3. 4.8.1  Program  P01ASD  (UNIT  INDEX) 

Program  P01ASD  (unit  index)  retrieves  the  'WICG'  INFOS  index,  sorts  it 
by  the  first  character  of  the  geographic  identifier  (GG07) ,  and  retrieves 
selected  elements  from  the  INFOS  data  base  using  the  newly  sorted  index.  Two 
report  formats  are  produced  from  the  selected  elements: 

o  TOTAL-PRINT  (file  A01ASD) .  A  statistical  print  of  all  airfields 
arranged  and  totaled  by  country,  section,  branch,  free  world 
including  CONUS,  free  world  excluding  CONUS,  and  CONUS  using  air¬ 
field  symbol  (GF03) ,  runway  length  (AR02),  and  runway  surface 
charting  code  (AR05)  as  delimiting  criteria. 

o  UNIT-PRINT  (file  B01ASD) .  A  statistical  print  of  all  airfields 
arranged  and  totaled  by  country,  section,  branch,  free  world 
including  CONUS,  free  world  excluding  CONUS,  and  CONUS  using  air¬ 
field  symbol  (GF03)  as  delimiting  criteria.  Within  each  country 
total  a  one  line  printout  of  each  airfield,  sorted  in  B.E.  Number 
order,  is  supplied. 
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3. 4. 8. 2  Program  P09ASD  (SUBSAR) 


Program  P09ASD  (SUBSAR)  retrieves  selected  elements  from  the  INFOS  data 
base  using  pre-defined  airfields  and  report  formats,  and  produces  a  one  line 
printout  per  airfield  within  the  output  report.  The  output  report  may  have 
the  following  characteristics: 

o  Sorting  up  to  three  passes 

o  Page  breaking  on  first  sort  pass  element 

o  "R"  airfields  may  be  included  or  excluded 

o  Specific  INFOS  data  base  elements  may  be  sanitized 

o  Selection  of  security  classification 

o  A  title  page  may  be  included 

o  Choice  of  multiple  header  lines  for  one  line  printout  lines 
o  Up  to  triple  spacing  of  one  line  printout  lines. 
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3. 4. 8, 3  NAME  CHANGE 


This  program  lists  changes  that  have  occurred  against  selected  elements 
in  the  AAFIF  data  base  on  a  weekly  and  semiannual  basis.  Two  report  formats 
are  output  and  sorted  according  to  user  preference:  'NAMCHG'  and  'CHGSLIP.’ 
The  report  outputs  are  unclassified  and  used  in  the  maintenance  of  certain 
F LIP  products,  NAV  and  planning  charts,  and  DoD  air  facility  library  records. 

3. 4. 8. 4  HISTDUP 

This  program  produces  a  card  code  formatted  dump  to  magnetic  tape  of  all 
airfields  in  the  AAFIE  data  base  or  uses  the  Boolean  retrieval  file  as  input 
to  dump  selected  airfields. 

3. 4. 8. 5  A1FUPD 

This  program  creates  the  Defense  Intelligence  Agency  Automated  Intelli¬ 
gence  file  (DIA-AIF)  that  reflects  air  facility  intelligence  changes,  addi¬ 
tions,  and  deletions  for  a  select  set  of  DIA  AAFIF  data  base  elements.  Input 
to  this  program  is  the  Air  Facility  Subsystem  transaction  log  and  output  is 
a  magnetic  tape  reflecting  the  necessary  transactions. 

3. 4. 8. 6  ASSOTW 

This  program  builds  the  Air  and  Sea  Plane  Stations  of  the  World  (ASSOIW) 
magnetic  tape  file  by  retrieving  and  formatting  airfield  data  from  the  AAFIF 
data  base  using  the  ASSOTW  transaction  log  as  input.  The  ASSOTW  magnetic  tape 
file  is  then  processed  on  the  Electron  Beam  Recorder  (EBR) . 

3.4.9  Operating  Instructions 

This  section  describes  the  operator  interface  with  the  system  for 
operational  as  well  as  system  loading  and  test  procedures. 

o  To  list  a  program  use  the  CLI  command: 

LIST  **.FR 

Where  **  is  the  file  name. 
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To  print  a  program  at  the  terminal  use  the  following  CLI  command: 


TYPE  **.FR 

o  To  print  a  program  at  the  line  printer  use  the  following  CLI 
command: 

PRINT  *  * . FR 

o  To  compile  a  program  use  the  following  CLI  command: 

FORT  *  * . FR 

3. 4. 9.1  Operational  Programs 

o  To  run  on-line  a  set  of  programs  execute  the  following  'MC'  files. 
AFS.MC  On-Line  Data  Management  Programs 

RET. MC  Edit  Table  Programs 

3. 4. 9. 2  Directory  Selection 

The  preceding  programs  represent  the  'operational'  version  of  the 
developed  software  which  has  been  collected  and  assembled  in  one  directory 
(DIR  PETE).  There  also  exists  a  'developmental'  and  'debug'  version  in 
another  directory  (DIR  NEHL)  which  has  many  of  the  built  in  software  tests 
and  error  messages  left  activated.  The  latter  also  contains  the  programs 
for  table  generations,  testing,  and  systems  loading. 

To  select  the  desired  directory  use  the  following  CLI  commands: 

DIR  PETE  (Operational  Programs) 

DIR  NEHL  (Test  and  System  Loading  Programs) 

3. 4. 9. 3  Table  Generation  and  Loading  Programs 

To  produce  header  and  tab  settings  for  the  on-screen  generation  of  label 
book  tables  type: 

LDI SPLAY 

To  produce  a  hardcopy  printout  of  all  label  book  tables  use  the  MC  file: 
PLABL 
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To  process  all  label  pages  and  to  load  the  created  load  file  to  INFOS 
type  (MC  file) : 

CLBL 

To  produce  header  and  tab  settings  for  the  on-screen  generation  of 
Format  tables  and  Logical  tables  use  programs: 

FHEAD  (Format  tables) 

LHEAD  (Logical  tables) 

For  'wholesale'  inputs  of  edit  tables  via  the  cardreader  use  program: 
CEDT 

For  the  on-line  testing  and  modification  of  a  specific  edit  table  (with 
automatic,  subsequent  reloading  to  INFOS)  use  the  program  package: 

ET 

For  a  documentation  of  the  test  session  through  subsequent  hardcopy 
output  use  the  CLI  commands: 

PRINT  SNAME  (hardcopy) 

TYPE  SNAME  (screen  review) 

(Substitute  NAME  with  the  actual  name  of  the  session  file  as  requested  by  ET 
and  input  during  the  test  session.) 

For  the  'wholesale'  loading  to  INFOS  of  all  current  edit  tables  use: 

EPRT 

This  program  also  produces  two  RDOS  files: 

o  ETL1ST,  a  comprehensive  listing  of  all  loaded  and  missing  tables 
(edit  table  system  summary) ,  and 

o  EREPRT,  a  listing  of  all  formal  errors  detected  during  the  loading 

cycle.  An  on-line  generated  output  option  allows  the  user  to  expand 
this  listing  to  include  the  contents  of  each  loaded  table  in  its 
original  RDOS  form. 
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To  obtain  a  hardcopy  output  of  those  created  load  files  use: 

PRINT  ETLIST  (edit  table  loading  summary) 

PRINT  EREPRT  (detected  errors  and  table  contents) 

3. 4.9.4  Function  Analysis  of  Logical  Tables 

In  DIR  NEHL  a  special  version  of  the  AFF  program  exists  that  contains 
detailed  error  and  diagnostic  messages  for  the  UPDATE  function.  It  also 
provides  a  complete  hardcopy  output  of  the  Logical  check  procedures  at  the 
end  of  the  Update  cycle.  Since  all  tables,  their  load  segments,  and  the 
evaluation  results  are  printed,  a  complete  analysis  of  the  many  (otherwise 
unseen)  functions  can  be  made. 

The  system  is  very  protective  against  'wrong'  inputs,  to  the  point  that 
it  might  not  be  possible  to  update  certain  portions  of  an  airfield.  The 
provided  capability  is  useful  therefore  in  specifically  answering  the  question 
which  of  the  following  items  have  caused  an  update  rejection: 

o  unacceptable  (though  format-correct)  user  input 

o  'old'  data  base  entry  that  does  not  conform  with  a  'new'  logical 
edit  requirement 

o  wrong  logical  table  entry 

ttefore  large-scale  operations  commence,  it  is  anticipated  and  recommended 
that  a  thorough  break-in  period  be  used  to  vigorously  exercise  the  system  in 
order  to  detect  and  to  resolve  most  of  these  potential  differences.  To 
initiate  the  provided  analysis  capability  use  the  program: 

AFL  (for  UPDATE  with  printout  of  Logical  edit  checks) 


SECTION  IV 


CONCLUSIONS  AND  RECOMMENDATIONS 


4 . 0  General 

Main  purpose  of  the  pilot  effort  was  to  demonstrate  the  feasibility  of 
the  design  on  a  limited  1/15  data  base  volume.  The  conducted  functional  and 
volume  tests  thus  constituted  a  major  evaluation  criteria  for  determining 
whether  to  continue  Phase  II  of  the  program  and,  in  the  case  of  program 
continuation,  to  pinpoint  potential  areas  of  improvement. 

4.1  Conclusions 

The  tests,  as  conducted  during  the  Air  Facilities'  test  and  evaluation 
period,  conclusively  demonstrated  that  the  functions  designed  and  implemented 
match  the  requirements  outlined  in  the  Statement  of  Work. 

Three  types  of  tests  were  performed.  The  inspection  tests  proceeded  as 
conceived  and  were  accepted  as  is.  They  dealt  primarily  with  vendor  supplied 
equipment  and  systems  software.  The  function  tests  dealt  with  the 
required  processing  functions  as  designed  by  Synectics  and  implemented  through 
specific  software.  These  tests  proceeded  as  conceived  and  were  accepted  as 
each  function  test  was  demonstrated,  with  exceptions  and  suggestions  for  modi¬ 
fications  noted.  The  major  conclusion  from  the  volume  tests  was  that  the 
new  on-line  system,  in  a  2-week  period  using  one  analyst,  successfully  accom¬ 
plished  the  work  of  the  100-150  analysts  who  would  generate  the  same  volume 
in  a  2-week  period  with  the  old,  card-oriented  processing  system. 

The  prime  conclusion  that  can  be  drawn  from  the  Air  Facilities'  test 
and  evaluation  exercise  is  that  the  functions,  as  implemented  in  the  pilot 
system,  in  general  performed  as  proposed,  or  better,  over  a  1/15  data  base 
and  transaction  volume. 

4.2  Recommendations 

It  is  recommended  that  the  functions,  as  demonstrated  during  the  Air 
Facilities  Pilot  system  be  extended  and  implemented  to  cover  the  full  Air 
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Facilities  data  base  and  processing  volume.  Major  emphasis  in  this  Phase  II 
effort  should  be  placed  on  an  extended  data  base  structure  with  automatic 
loading  support,  improved  processing  capabilities  for  application  programs 
that  produce  (off-line)  reports  and  tapes,  and  a  full  expansion  to  remote, 
multi-user  access  for  the  on-line  data  base  maintenance  system. 


